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APPELLANT'S AMENDED BRIEF 

Dear Sir: 

This Amended Brief is filed pursuant to a Notification of Non- 
Compliant Appeal Brief mailed 2 0 October 2 006 in the matter of 
the above-identified application. 

The only amendment to this Appeal Brief appears in the Status 
of Claims section on page 4, paragraph 1, wherein inadvertent 
reference to claim 2 has been removed. 
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Real Party in Interest 

Mainline Corporate Holdings, Limited, an Irish Company is the 
real party in interest and the assignee of this application. 
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Related Appeals and Interferences 



Appellant is aware of no related appeals, interference, and/or 
other proceedings relevant to this discussion. 
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Status of Claims 

Claims 1, 3-8, 10, 12-23, 25-40, of which claims 1, 10, 23, 
and 3 7 are independent claims, are presented herein. Claims 1- 
8, 10, 12-23, 25-40 have been rejected, and claims 1, 3-8, 10, 
12-23, 25-40 are on appeal. 

Appendix A provides a clean copy of all claims on appeal. 

Claims 1, 3, 10, 12, 23, and 25 stand rejected under 35 
U.S.C. 102(e) as being anticipated by Boesch et al . , U.S. Patent 
No. 5,870,473 (hereinafter Boesch). 

Claims 4-8, 13-16, and 26-30 stand rejected under 35 U.S.C. 
103 (a) as being unpatentable over Boesch in view of Boston, EP 
0251619. 

Claims 17-22 and 31-37 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Boesch and Boston in view of Levine et 
al., WO 95/12169 (hereinafter Levine). 

Although not expressly stated, claims 38-40 are presumed to 
be rejected under 35 U.S.C. 103(a) as being unpatentable over 
Boesch and Boston in view of Levine. 

Appendix B provides copies of the Boesch, Boston, and Levine 
references . 
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Status of Amendments 



No amendments have been filed subsequent to the rejections 
set forth in a final Office Action, dated 1 June 2006. 
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Summary of Claimed Subject Matter 

Appendix C provides copies of drawing sheets 1-10 containing 
FIGs. 1-10, some of which are discussed herein. 

In accordance with at least one embodiment, the present 
invention pertains to a data processing method, data processing 
system, and a computer program for determining a preferred 
currency for association with a payment card transaction between 
a merchant and a payment card cardholder. This embodiment of 
the present invention is therefore directed at automatically 
determining the currency of a charge, debit or credit card used 
in a transaction between a cardholder and a merchant and 
associating the determined currency with the transaction, so 
that a cardholder may conduct the transaction in a currency 
which differs from the currency ordinarily used by the merchant, 
with no input required from the merchant . 

The elements of each of the independent claims, mapped to 
the specification by page number and line number and mapped to 
the drawings, are presented below. 

Independent Claim 1 

The preamble of claim 1 recites a "data processing method 
performed in a data processing system for determining a 
preferred currency for association with a payment card 
transaction between a merchant and a payment card cardholder." 
The data processing method is generally discussed on page 10, 
line 6-31, and is illustrated in Figure 5. Figure 5 illustrates 
a flowchart of the operation of the present invention, 
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specifically a task 54, in combination with conventional 
methodology at a task 53. The data processing method is 
discussed in greater detail on page 14, line 16, through page 
16, line 16, and is shown in FIG. 8. The software and/or 
hardware for performing the steps according to the invention are 
at a data processing system which may be a terminal, payment 
router, an authorization host, or any combination of these, as 
disclosed at page 12, lines 1-3. 

A first claim element recites "obtaining the card number of 
the payment card." An obtaining operation 205 is discussed in 
the specification at page 14, lines 16-20, and is illustrated in 
FIG. 8. The card number is obtained when the merchant swipes 
205 the card in the magnetic stripe reader of the point of sale 
terminal . 

A second claim element recites "in said data processing 
system, identifying an identifier code from said card number." 
An operation 50 is discussed in the specification at page 10, 
lines 6-8, and shown in FIG. 5, in which an identifier code is 
extracted from the payment card details. 

A third claim element recites "determining the operating 
currency for said identifier code by comparing said identifier 
code with entries in a table wherein each entry in said table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code." An operation 51 is 
discussed in the specification at page 10, lines 16-30, and is 
shown in FIG. 5. The identifier code is compared 51 with 
entries in a bank reference table, an example of which is shown 
in FIG. 6, which contains a list of issuer identifier codes. 
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Each issuer identifier code 60(l-n) in the table of FIG. 6 has 
an associated entry 61(l-n) containing an associated currency, 
which corresponds to the currency of payment cardholders 
accounts of the issuer. If an entry is found in the bank 
reference table for the identifier code, the operating currency 
is determined by extracting the associated currency 
corresponding to the issuer code. A similar operation 210 is 
discussed in the specification at page 14, lines 22-23, and is 
shown in FIG. 8. The terminal software searches through the 
Bank Reference table and checks 210 for an entry corresponding 
to the issuer (identifier) code from the card number to 
determine the operating currency. 

A fourth claim element recites "setting the currency for 
association with the payment card transaction as the determined 
operating currency for the identifier code." The claimed 
setting element is discussed in general terms at page 10, lines 
2 6-30, and elements 52, 53, and 54, shown in FIG. 5. The 
claimed setting element is discussed in the specification in 
more specific terms at page 14, lines 23-26, and shown in FIG. 
8. That is, if an entry is found the currency for the operation 
is set 215 to that of the payment card. If no entry in the Bank 
Reference table is found the currency is set 220 to that of the 
merchant . 

Independent Claim 10: 

The preamble of claim 10 recites a "data processing system 
for determining a preferred currency for association with a 
payment card transaction, the payment card having a card number, 
between a merchant and a payment card cardholder." One data 



APPELLANT'S AMENDED BRIEF 
Serial No. 09/613,679 
Page 9 

processing system is exemplified as being a point of sale 
terminal 70 discussed in the specification on page 12, line 5, 
through page 13, line 14. The terminal 70 executes the 
methodology discussed in connection with claim 1 which is 
discussed in the specification at page 14, line 16, through page 
16, line 16. 

A first claim element of claim 10 recites "means for 
obtaining the card number of the payment card from the 
cardholder." The terminal includes a magnetic strip reader 71 
and an alphanumeric and function keypad 72, which are discussed 
in the specification at page 12, lines 15-18, and shown in FIG. 
7. Card details (card number, expiry date, and name of the 
cardholder) are obtained 205 either by swiping a payment card 
through the magnetic strip reader 71 or using the keypad 72. 

A second claim element of claim 10 recites "means for 
identifying an identifier code from said card number." The 
terminal software includes code which caries out functions that 
include: modem control, card reading, bank reference table 
management, and so forth, as discussed in the specification at 
page 12, line 27, through page 13, line 31. The specification 
further discusses the terminal software obtains an identifier 
code from the card number at page 14, lines 23-26. 

A third claim element of claim 10 recites "means for 
determining the operating currency for said identifier code by 
comparing said identifier code with entries in a table, wherein 
each entry in said table contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code." The specification discusses the terminal software 
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searches through the Bank Reference table (shown in FIG. 6) and 
checks for an entry corresponding to the code obtained from the 
card number at page 14, lines 22-23. 

A fourth claim element of claim 10 recites "means for setting 
the currency for association with the payment card transaction 
as the determined operating currency for the identifier code." 
Applicants specification teaches at page 14, lines 23-26 that if 
an entry is found the currency for the transaction is set 215 to 
that of the payment card. If no entry in the Bank Reference 
table is found the currency is set 220 to that of the merchant. 

Independent Claim 23: 

The preamble of claim 23 recites a computer program encoding 
a set of computer instructions for use in a computing device for 
determining a preferred currency for association with a payment 
card transaction, the payment card having a card number, between 
a merchant and a payment card cardholder. A first claim element 
of claim 23 recites a computer code section which when executed 
on the computing device obtains the card number of the payment 
card from the cardholder. A second claim element recites a 
computer code section which when executed on the computing 
device identifies an identifier code from said card number. A 
third claim element recites a computer code section which when 
executed on the computing device determines the operating 
currency for said identifier code, by comparing said identifier 
code with entries in a table, wherein each entry in said table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code. A fourth claim element 
recites a computer code section which when executed on the 
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computing device sets the currency for association with the 
payment card transaction as the determined operating currency 
for the identifier code. 

The computer code sections correspond with the method 
operations recited in claim 1 and the specification teaches that 
software and/or hardware performs the steps according to the 
invention at page 12, lines 1-3. The claimed computer program 
is software. Similarly, the claimed computer code sections are 
also software. These code sections are discussed in terms of 
the methodology discussed on page 14, line 16, through page 16, 
line 16, and shown in FIG. 8. Consequently, these claim 
elements have been previously mapped to the specification and 
drawings above and are not repeated for brevity. 

Independent claim 37: 

The preamble of claim 37 recites a "method of operating a 
data processing system to conduct a financial transaction for 
the exchange of money provided by a payment card cardholder for 
a good or service provided by a merchant.' 7 The obtaining, 
identifying, and determining operations are similar to those set 
forth in connection with claim 1. Consequently, these claim 
elements have been previously mapped to the specification and 
drawings above and are not repeated for brevity. 

A fourth element of claim 37 recites "indicating said 
operating currency as being a preferred currency of exchange for 
said financial transaction." This operation utilizes slightly 
different language than recited in claim 1. Nevertheless, the 
indicating operation is discussed in the specification at page 
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14, lines 23-26, wherein the preferred currency of exchange is 
indicated as l)if an entry is found the currency for the 
transaction is set 215 to that of the payment card or 2) if no 
entry in the Bank Reference table is found the currency is set 
22 0 to that of the merchant. 

A fifth element of claim 37 recites "receiving a cardholder 
reply in response to said indicating activity" and a sixth 
element of claim 37 recites "completing said financial 
transaction in response to said receiving activity." A 
cardholder reply is discussed in the specification at page 15, 
lines 7-16 and is shown in FIG. 8. A reply by the cardholder 
entails a consent to or rejection of an offer at 270. When the 
cardholder consents to the offer at 270, the financial 
transaction is completed in the currency of the cardholder, as 
discussed in the specification at page 15, line 15, through page 
16, line 16. 

Dependent claims 3, 12, 25: 

Claims 3, 12, and 25 share similar features. In particular, 
each of claims 3, 12, and 25 include the feature of the 
preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code. This feature is discussed in the specification 
at page 14, lines 24-26, and is shown in FIG. 8 at element 220. 

Dependent claims 4, 14, 26: 



Claims 4, 14, and 26 share similar features. In particular, 
each of claims 4, 14, and 26 include the features of the 
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cardholder being prompted as to whether the transaction is to be 
conducted in the preferred currency, converting the transaction 
amounts to equivalent amounts in the preferred currency, and 
presenting these amounts for review by the cardholder. This 
feature is discussed in the specification at page 15, lines 7- 
16, and is shown in FIG. 8 at elements 265, 270, and 275. 

Dependent claims 5 and 27: 

Claims 5 and 27 share similar features. In particular, each 
of claims 5 and 27 include the feature of at least one of the 
transaction amounts is converted to an equivalent amount in the 
preferred currency and is presented to the cardholder. This 
feature is discussed in the specification at page 16, line 6-16, 
and is shown in FIG. 8. A transaction slip is produced 260 
which details transaction values in the merchant currency, 
transaction value in cardholders currency, and other 
information. A copy of this transaction slip is produced for 
the merchant and the cardholder. 
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Grounds of Rejection to Be Reviewed on Appeal 

The 1 June 2006 Final Office Action rejects claims 1, 3, 10, 
12, 23, and 25 under 35 U.S.C. 102(e) as being anticipated by 
Boesch. In addition, claims 4-8, 13-16, and 26-30 were rejected 
under 35 U.S.C. 103(a) as being unpatentable over Boesch in view 
of Boston, and claims 17-22, 31-37, and 38-40 were rejected 
under 35 U.S.C. 103(a) as being unpatentable over Boesch and 
Boston in view of Levine. 

These rejections are formally delineated in the Status of 
Claims section of this document. 

The following three grounds of rejection are presented for 
review : 

1: Whether claims 1, 3, 10, 12, 23, and 25 are unpatentable 
under 35 U.S.C. 102(e) as being anticipated by Boesch. 

2: Whether claims 4-8, 13-16, and 26-30 are unpatentable under 
35 U.S.C. 103(a) over Boesch in view of Boston. 

3: Whether claims 17-22 and 31-40 are unpatentable under 35 
U.S.C. 103(a) over Boesch and Boston in view of Levine. 
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Arguments 

Grounds of Rejection 1 -- Claims 1, 3, 10, 12, 23, and 25 

Independent Claims 1, 10, and 23: 

Regarding claim 1, the 1 June 2006 final Office Action to 
this application alleges that Boesch teaches a data processing 
method performed in a data processing system for determining a 
preferred currency for association with a payment card 
transaction between a merchant and a payment card cardholder. 
The final Office Action cites a passage at col. 11, lines 26-65, 
and Figures 4K and 5H as an alleged teaching of the claim 1 
limitation of obtaining the card number of the payment card. 
The final Office Action cites a passage at col. 12, lines 16-18, 
as an alleged teaching of the claim 1 limitation of the data 
processing system, identifying an identifier code from the card 
number. In addition, the final Office Action cites a passage at 
col. 12, line 50, through col. 13, line 10, as an alleged 
teaching of the claim 1 limitation of determining the operating 
currency for the identifier code by comparing the identifier 
code with entries in a table, wherein each entry in the table 
contains an issuer identifier code or range of issuer identifier 
codes and a corresponding currency code. The final Office 
Action also cites a passage at col. 14, lines 17-30, as an 
alleged teaching of the claim 1 limitation of setting the 
currency for association with the payment card transaction as 
the determined operating currency for the identifier code. 

Boesch discloses a sophisticated system under which customer 
purchases from merchants may be securely made over the Internet. 
The thrust of the disclosure is directed toward providing secure 
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communications. In one embodiment, the secure communications 
occur through an electronic transfer system in which a customer 
and a merchant can conduct a transaction whereby the customer 
can purchase a product from the merchant and pay for the product 
using electronic cash. 

Boesch teaches of a customer paying for products with 
electronic cash, and defines electronic cash as being a 
representation of funds (real cash, credit, etc.), at col. 6, 
lines 51-53. In order to pay for products with electronic cash, 
Boesch further teaches that a customer "loads" funds associated 
with a bound instrument (credit card, debit card, demand deposit 
account, or other financial instruments) to a persona of the 
customer user (col. 7, lines 53-58). The electronic cash is 
subsequently "unloaded" (or transferred) from the persona of the 
customer user to another bound instrument, such as that of a 
merchant. In other words, funds are "loaded" into and 
"unloaded" from a cash container (col. 21, lines 16-24). 

The Boesch teaching of electronic cash is consistent with 
conventional definitions of electronic cash, electronic money, 
electronic currency, digital currency, and the like which refers 
to money which is represented, held, and exchanged only in 
electronic form. Some examples of the use of electronic cash 
include internet/online banking, debit cards, online bill 
payments and internet business. Disadvantages to the use of 
electronic cash include fraud, failure of the technology, 
possible tracking of individuals, and the like. Boesch attempts 
to solve some of these problems by implementing a system and 
method for increasing the efficiency of secure message 
processing when paying for a product using electronic 
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funds/cash. 

In contrast, Appellant's invention as defined in claim 1 is 
directed toward a method "for determining a preferred currency 
for association with a payment card transaction between a 
merchant and a payment card cardholder." Appellant describes a 
payment card transaction as a transaction in which a physical 
medium, i.e., a payment card, such as a credit card, charge 
card, debit card, and the like, is utilized by a cardholder of 
the payment card to make a purchase. Appellant's teaching is 
consistent with conventional definitions of the term payment 
card. In particular, a payment card covers a range of different 
cards that can be presented by a cardholder to make a payment. 
A payment card is typically backed by an account holding funds 
belonging to the cardholder or offering credit to the 
cardholder . 

Consequently, the Boesch teaching of an electronic cash 
transaction (in which funds are "loaded" to a persona, or cash 
container, associated with a customer user) between a merchant 
user and a customer user is not a teaching of a "payment card 
transaction between a merchant and a payment card cardholder" as 
recited in independent claim 1. While the Office Action alleges 
that Boesch teaches a payment card transaction, this allegation 
is a distortion and misrepresentation of that which Boesch 
actually teaches. That is, the merchant user and customer user 
within the Boesch system engage in an electronic cash 
transaction, which is not a payment card transaction. Indeed, 
the merchant user has no knowledge of any particular payment 
card held by the payment card cardholder or other mode of 
payment other than electronic cash. 
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Nor is Boesch directed toward currency determination for a 
payment card transaction between a merchant and a customer. The 
"determining" operation of independent claim 1 determines the 
operating currency for the identifier code by comparing the 
identifier code with entries in a table wherein each entry in 
the table contains an issuer identifier code or range of issuer 
identifier codes and a corresponding currency code. The 
"setting" operation of independent claim 1 then sets the 
currency for association with the payment card transaction as 
the determined operating currency for the identifier code. 

Boesch does not teach Appellant's "determining" operation 
despite Office Action allegations to the contrary. The passage 
cited from Boesch at col. 12, line 50, through col. 13, line 10, 
as an alleged teaching of Appellant's "determining" operation 
discloses a portion of a server persona data structure 12 0 that 
stores data relating to the customer users and merchant users 
that have registered with the Boesch electronic transfer system. 
A portion of the server persona data structure 120 is 
illustrated in FIG. 4D. In particular, the cited passage and 
associated FIG. 4D discloses a table of data illustrating fields 
of instrument binding data 12 OH. A "persona" of the Boesch 
reference is essentially a collection of data relating to a 
specific customer user or merchant user. The instrument taught 
by Boesch is a financial instrument, and may include a credit 
card, debit card, demand deposit account (DDA) , or the like. 

Boesch teaches in the cited passage that instrument binding 
data 120H includes a field 120H.16 having a flag indicating 
whether the bound instrument is enabled for sale transactions, 
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and when field 120H.16 indicates that the bound instrument is 
enabled for sale transactions, a limit in customer user's chosen 
(i.e., native) currency is stored in field 120H.17. Instrument 
binding data 120H also includes a field 120H.18 indicating 
whether the bound instrument is enabled for credit/return 
transactions. A credit/return transaction is an operation where 
a merchant credits the customer persona 120.1 in lieu of 
providing the product originally agreed to. When field 120H.18 
indicates that the bound instrument is enabled for credit/return 
transactions, a limit in customer user's chosen (native) 
currency, per credit/return transaction, is stored in a field 
120H.19. 

The Boesch instrument binding data 12 OH is illustrated as a 
table in Figure 4D, and of course, a table typically has 
entries. However, Appellant's determining operation of claim 1 
recites determining the operating currency for the identifier 
code by comparing the identifier code with entries in a table 
wherein each entry in the table contains an issuer identifier 
code or a range of issuer identifier codes and a corresponding 
currency code. Thus, even if one somehow equates the data 
structure 120 of instrument binding data 120H with Appellant's 
claimed table, the instrument binding data 120H is still lacking 
entries wherein each entry contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code. Rather, the Boesch table/data structure merely indicates 
that a user's chosen (native) currency for some operations may 
be specified. As stated in W.L. Gore & Associates v. Garlock 
Inc . , 220 USPQ 303, 313 (Fed. Cir. 1983), cert, denied, 469 U.S. 
851 (1984) : 
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Anticipation requires the disclosure in a single 
prior art reference of each element of the claim under 
consideration. 

Boesch simply does not anticipate Appellant's invention of 
claim 1 because Boesch does not disclose a payment card 
transaction' between a merchant and a payment card cardholder. 
Moreover, since the Boesch table of instrument binding data 120H 
is lacking the claimed entries wherein each entry in the table 
contains an issuer identifier code or a range of issuer 
identifier codes and a corresponding currency code, no 
comparison can be made between an identifier code identified 
from the card number of the payment card and these absent 
entries in order to determine the operating currency for the 
identifier code. As such, the rejection of independent claim 1 
under 35 U.S.C. §102 (a) was improper. 

Nor is Appellant's invention as defined in claim 1 obvious in 
view of Boesch. It should be noted that an "identifier code" is 
defined in Appellant's specification as the portion of a card 
number of a payment card which distinguishes it between card 
issuers. An "issuer identifier code" is defined in Appellant's 
specification as a code contained in Appellant's claimed table, 
also known as a bank reference table ( ' BRT ' ) . This issuer 
identifier code is associated with a currency in the claimed 
table. The associated currency corresponds to the currency of 
the payment card cardholder accounts for the issuer identified 
by the issuer identifier code. Thus, Appellant's claimed table 
(BRT) contains multiple entries of issuer identifier codes and 
corresponding currency codes. 

The Boesch reference teaches that a customer-merchant 
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transaction may take place in a multiple currency environment. 
But that teaching falls far short of suggesting how the currency 
is set, as recited in claim 1. How the currency is set, in 
accordance with claim 1, is through a comparison made between 
the identifier code from the card number of the payment card and 
entries presented in the table to determine an operating 
currency. 

In contrast, Boesch expressly teaches how a currency is set 
for the Boesch system and that is through explicit customer 
entry of a default currency by the customer user during a 
registration process (col. 80, lines 5-26). This registration 
process occurs prior to binding a financial instrument, such as 
a bank account, credit card, or debit card, for use during 
electronic cash transactions. Consequently, the Boesch default 
currency corresponds with the customer user's chosen preference 
regardless of any financial instrument bound to that customer's 
persona in the Boesch electronic transfer system. 

Therefore, no table of entries containing issuer identifier 
codes and corresponding currency codes, such as that recited in 
claim 1, is required in the system of Boesch. The explicit 
customer entry of a default currency during a registration 
process as taught by Boesch suggests away from Appellant's 
invention of claim 1 in which a comparison is made between the 
identifier code identified from the card number of the payment 
card and entries in the table to determine an operating 
currency, and the currency is set for association with the 
payment card transaction as the determined operating currency. 



The invention of claim 1 is directed to a method for 
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automatically determining a preferred currency for association 
with a payment card transaction that requires no user input. 
The automatic character of the claimed data processing method is 
intrinsic as a result of performing the claimed steps of 
obtaining, identifying, determining the operating currency 
utilizing a table containing issuer identifier codes and 
corresponding currency codes, and setting the currency for the 
payment card transaction as the determined operating currency 
for the identifier code. The pre-emptive, explicit customer 
entry of a default currency in the Boesch system during a 
registration process before conducting any transaction is not 
automatic since input from the customer/user/cardholder at a 
stage preceding a transaction is necessary. 

For the purposes of the Boesch system, explicit customer 
entry of a default currency during a registration process 
executed prior to binding a particular financial instrument 
(bank account, credit card, debit card, etc.) is sufficient. 
That is, there is no motivation or suggestion to modify the 
Boesch system to include Appellant's claimed table containing 
entries of issuer identifier codes and a corresponding currency 
codes because such a table would serve no purpose in the Boesch 
system. 

It is only Appellant's specification that teaches of a data 
processing method performed in a data processing system for 
determining a preferred currency for association with a payment 
card transaction between a merchant and a payment cardholder, as 
recited in claim 1. Moreover, it is only Appellant's 
specification that teaches of determining the operating currency 
for an identifier code identified from a card number of the 
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payment card by comparing the identifier code with entries in a 
table wherein each entry in the table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and setting the currency for 
association with the payment card transaction as the determined 
operating currency for the identifier code. Appellant's 
invention of claim 1 provides means by which a cardholder can be 
sure of an exact value of a payment card transaction when 
traveling abroad by allowing the cardholder to make payments 
and/or view a transaction amount in their home currency rather 
than in the currency of the merchant with whom they are 
conducting business. Consequently, Appellant's invention as 
defined in claim 1 is not rendered obvious in view of the Boesch 
reference . 

Unlike claim 1, claim 10 is expressed in the terms of a 
system. But in spite of certain differences, claims 1 and 10 
share some similar features. For example, claim 10 includes the 
limitations of means for determining the operating currency for 
the identifier code by comparing the identifier code with 
entries in a table, wherein each entry in the table contains an 
issuer identifier code or range of issuer identifier codes and a 
corresponding currency code, and means for setting the currency 
for association with the payment card transaction as the 
determined operating currency for the identifier code. 
Accordingly, claim 10 is neither anticipated by nor rendered 
obvious in view of Boesch for substantially the same reasons as 
are set forth above in connection with claim 1. 



Unlike claim 1, claim 23 is expressed in the terms of a 
computer program. But in spite of certain differences, claim 23 
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also shares some similar features with claim 1, including the 
features generally discussed above in connection with claim 1. 
Accordingly, claim 23 is neither anticipated by nor rendered 
obvious in view of Boesch for substantially the same reasons as 
are set forth above in connection with claim 1. 

For the reasons set forth above, the rejection of independent 
claims 1, 10, and 23 under 35 U.S.C. §102 (e) as being 
anticipated by Boesch was improper. In addition, claims 1, 10, 
and 23 are not obvious in view of Boesch. Appellant therefore 
believes independent claims 1, 10, and 23 to be allowable. 
Accordingly, the Board is respectfully requested to reconsider 
claims 1, 10, and 23. 

Claims 3, 12, and 25: 

Claim 3 depends from independent claim 1. While the previous 
discussion was specifically directed to independent claim 1, the 
limitations of claim 1 are read into dependent claim 3. 
Accordingly, claim 3 is believed to be allowable by reason of 
dependency. Claim 3 also includes the further limitation 
wherein the preferred currency is set to a default currency of 
the merchant when no operating currency can be determined for 
the identifier code. The Final Office Action cites a passage in 
Boesch at col. 13, lines 3-33 as an alleged teaching of 
Appellant's invention of claim 3. 

As discussed in detail in connection with claim 1, no 
operating currency can be determined for the identifier code, 
because Boesch fails to teach or suggest Appellant's limitations 
of claim 1 of comparing the identifier code with entries in a 
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table, and each entry containing an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code . 

In addition, Appellant respectfully disagrees with the Office 
Action allegation that Boesch teaches the further limitation of 
claim 3. There is no teaching or suggestion within the Boesch 
reference of setting the preferred currency of the merchant 
because there is no table taught by Boesch that even remotely 
resembles Appellant's claimed table having entries wherein each 
entry in the table contains an issuer identifier code or range 
of issuer identifier codes and a corresponding currency code. 

The passage cited in col. 13, lines 3-33, as an alleged 
teaching of Appellant's limitations of claim 3 merely indicates 
that within the set of fields 120H. 1-120H. 28 that store data for 
each financial instrument bound to customer persona 12 0.1, and 
particularly within fields 120H.19, 120H.21, and 120H.23, 
certain limits may be set in a customer user's chosen native 
currency . The passage further teaches that if a native currency 
does not exist, the limit may be set in U.S. dollars. However, 
the customer user's chosen native currency is not a teaching of 
the preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code, as recited in claim 3, because the merchant 
need not have the same currency as the customer user. Likewise, 
the currency set in U.S. dollars is not a teaching of the 
preferred currency being set to a default currency of the 
merchant when no operating currency can be determined for the 
identifier code because the merchant need not be a U.S. merchant 
that deals in U.S. currency. As stated in W.L. Gore & 
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Associates, Inc. v. Garlock, Inc. , 220 USPQ 303, 312-13 (Fed. 
Cir. 1983), cert denied, 469 U.S. 851 (1984): 

To imbue one of ordinary skill in the art with 
knowledge of the invention in suit, when no prior art 
reference or references of record convey or suggest that 
knowledge, is to fall victim to the insidious effect of a 
hindsight syndrome wherein that which only the inventor 
taught is used against its teacher. 

It would be through hindsight gained through an understanding 
of Appellant's specification and claims that one could even 
consider setting a preferred currency to a default currency of 
the merchant when no operating currency can be determined for 
the identifier code especially in the absence of a teaching or 
suggestion of Appellant's claimed table having entries wherein 
each entry in the table contains an issuer identifier code or 
range of issuer identifier codes and a corresponding currency 
code. Of course, it is improper to use hindsight in making an 
obviousness rejection. Consequently, Appellant believes that 
Boesch fails to teach or suggest the limitations of claim 3. 

Claim 12 depends from independent claim 10, and claim 25 
depends from independent claim 23. Appellant therefore believes 
claims 12 and 25 to be allowable by reason of dependency. In 
addition, claims 12 and 25 share similar features with claim 3. 
Consequently, Appellant believes that Boesch fails to teach or 
suggest the limitations of claims 12 and 25 for the reasons set 
forth in connection with claim 3 . 

For the reasons set forth above, the rejection of claims 3, 
12, and 25 under 35 U.S.C. §102 (e) as being anticipated by 
Boesch was improper. Nor are claims 3, 12, and 25 rendered 
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obvious in view of Boesch. Appellant therefore believes claims 
3, 12, and 25 to be allowable. Accordingly, the Board is 
respectfully requested to reconsider claims 3, 12, and 25. 

Grounds of Rejection 2 -- Claims 4-8, 13-16, and 2 6-30 

Claims 4-8, depend directly or indirectly from independent 
claim 1. While the previous discussion was specifically 
directed to independent claim 1, the limitations of claim 1 are 
read into dependent claims 4-8. Accordingly, claims 4-8 are 
believed to be allowable by reason of dependency. Claims 13-16 
depend directly or indirectly from independent claim 10. 
Accordingly, claims 13-16 are also believed to be allowable by 
reason of dependency. Similarly, claims 26-30 depend from 
independent claim 23, and are also believed to be allowable by 
reason of dependency. In addition, claims 4-8, 13-16, and 26-30 
are allowable for independent reasons. 

Claims 4, 14, and 26: 

Claim 4 includes the limitation wherein the cardholder is 
prompted as to whether the transaction is to be conducted in the 
preferred currency, including the steps of converting the 
transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder. 

The final Office Action acknowledges that Boesch fails to 
teach the limitations of claim 4. However, the final Office 
Action alleges that Boston teaches the features of claim 4, 
citing a passage on page 5, paragraphs 3 and 4, and concludes 
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that it would have been obvious to modify Boesch to include the 
alleged teaching of Boston because such a modification would 
allow Boesch to have the transaction amount expressed in the 
foreign currency using the associated conversion rate. 

The present invention is concerned with effecting 
transactions in a multicurrency environment. Within the context 
of the present invention, for any individual merchant, 
individual transactions may take place using any one of a number 
of different currencies. As is discussed in more detail below, 
Appellant's claims define an invention that permits a payment 
card transaction to take place between a merchant and a customer 
using the customer's preferred currency. 

Boston does not disclose such a system. Rather, Boston 
discloses a system in which transactions take place exclusively 
in the currency of the merchant. More specifically, Boston 
fails to provide any teachings pertaining to converting the 
transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder, as recited in claim 4. Instead, Boston teaches the 
opposite . 

Boston discloses a transaction card that includes a processor 
and a memory in which a transaction limit represented in a base 
currency and one or more rates for converting the base currency 
into different foreign currencies can be stored. The Boston 
card is further configured with data input means for allowing 
the cardholder to select the desired currency and for updating 
the transaction limit and conversion rates. The passage on page 
5, paragraphs 3 and 4, of the Boston reference cited in the 
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final Office Action teaches that when a transaction is to be 
carried out in a foreign currency, the processor will convert 
the transaction limit from the base currency into a transaction 
limit represented in the foreign currency using the associated 
conversion rate. The Boston system can then compare a 
transaction amount expressed in the foreign currency and 
supplied through data entry to the converted transaction limit 
to determine if the transaction should be approved. Thus, the 
multi- currency capability of the Boston system is limited to 
expressing a transaction limit in one or more of several 
currencies, for verifying and/or validating a transaction, 
possibly as part of a transaction authorization procedure. That 
is, Boston does not associate the currency of the card with the 
transaction, i.e., change the currency of the transaction from 
the merchant currency to the cardholder currency at the point of 
sale . 

The Boston transaction amounts are not converted to 
equivalent amounts in the preferred currency. Rather, the 
cardholder enters the foreign currency and transaction limits in 
the base currency. The transaction limits are subsequently 
converted from the base currency to the foreign currency. The 
converted transaction limits are then compared with the 
unconverted transaction amounts in the foreign currency. Since 
the Boston transaction amounts are not converted to equivalent 
amounts in the preferred currency, as recited in claim 4, it 
follows that these equivalent amounts cannot be presented for 
review by the cardholder, as also recited in claim 4. 

Well-established patent practice dictates that a combination 
of prior art references cannot render obvious that which none of 
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the prior art teaches or suggests. As stated in In re Wood , 202 
USPQ 171, 174, (C.C.P.A. 1979) : 

The test for obviousness is not whether the features 
of one reference may be bodily incorporated into another 
ref erence .... Rather , we look to see whether combined 
teachings render the claimed subject matter obvious. 

Accordingly, the proper evaluation for determining 
patentability is to consider whether the prior art, and not 
Appellant's specification, suggests modifications which make the 
prior art methodology more closely resemble Appellant's data 
processing method and system. Moreover, proper evaluation for 
determining patentability is to consider whether combined 
teachings render the claimed subject matter obvious. 

Claim 4 recites operations that go beyond anything disclosed 
or suggested in either Boesch or Boston. Accordingly, together 
Boesch and Boston cannot be interpreted to suggest that which 
neither alone suggests. As such, claim 4 is believed to be 
allowable for the reasons set forth above. Claims 13 and 26 
share similar features with claim 4. Consequently, a 
combination of Boesch and Boston fails to render obvious the 
inventions of claims 13 and 26 for the reasons set forth in 
connection with claim 4 and claims 13 and 26 are believed to be 
allowable. The Board is respectfully requested to reconsider 
claims 4, 13, and 26. 

Claims 5-7 and 27-2 9: 

Claim 5 includes the limitation wherein at least one of the 
transaction amounts is converted to an equivalent amount in the 
preferred currency and is presented to the cardholder. Claim 5 
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is believed to be allowable for reasons similar to those set 
forth in claim 4. As explained above, it is the transaction 
limits that are converted from the base currency to the foreign 
currency, as opposed to the at least one of the transaction 
amounts which are actually converted to an equivalent amount in 
the preferred currency, as recited in claim 5. The converted 
transaction limits are then compared with the unconverted 
transaction amounts in the foreign currency. 

Since the Boston transaction amount (s) are not converted to 
an equivalent amount in a preferred currency, as recited in 
claim 5, it follows that the equivalent amount in the preferred 
currency cannot be presented to the cardholder, as also recited 
in claim 5 . 

Claim 5 recites operations that go beyond anything disclosed 
or suggested in either Boesch or Boston. Accordingly, together 
Boesch and Boston cannot be interpreted to suggest that which 
neither alone suggests. As such, claim 5 is believed to be 
allowable for the reasons set forth above. Claim 27 shares 
similar features with claim 5. Consequently, a combination of 
Boesch and Boston fails to render obvious the invention of claim 
27 for the reasons set forth in connection with claim 5 and 
claim 27 is believed to be allowable. 

Claims 6 and 7 depend from claim 5 and are believed allowable 
for the reasons set forth above in connection with claims 1 and 
5. Likewise, claims 28 and 29, depend from claim 27 and are 
believed allowable for the reasons set forth above in connection 
with claims 23 and 27. Accordingly, the Board is respectfully 
requested to reconsider claims 5-7 and 27-29. 
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Grounds of Rejection 3 -- Claims 17-22 and 31-40 

Claims 31 and 32, depend from independent claim 1 and the 
limitations of claim 1 are read into dependent claims 31 and 32. 
Accordingly, claims 31 and 32 are believed to be allowable by 
reason of dependency. Claims 17-22, 33, and 34 depend directly 
or indirectly from independent claim 10. Accordingly, claims 
17-22, 33, and 34 are also believed to be allowable by reason of 
dependency. Similarly, claims 35 and 36 depend from independent 
claim 23, and are also believed to be allowable by reason of 
dependency. Independent claim 3 7 includes features similar to 
those set forth in connection with claim 1, and is believed to 
be allowable for the reasons set forth in connection with claim 
1. Claims 38-40 depend directly or indirectly from claim 37, 
and are believed allowable by reason of dependency. 

Levine teaches a method and apparatus for distributing 
currency. Levine specifically teaches a magnetic stripe, 
electronic traveler's check (ETC) card issued to a customer and 
having a customer- selectable monetary value. The customer- 
selectable monetary value is configured with an encoded card 
number, including a bank identification number and an account 
number . 

The ETC taught by Levine allows persons who have purchased 
the ETC to make cash withdrawals or cash transfers from 
automatic teller machines (ATM' s) or other cash-dispensing 
terminals (see Levine at the abstract and page 3 lines 2 to 11) . 
In a multicurrency environment, the ATM machine with which the 
ETC is being used sends the ETC's bank identification number and 
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a code indicating the currency of the ATM to a "VisaNet" 
computer. Thus, two different currencies may be involved, one 
for the ATM and another for the ETC. Levine's VisaNet computer 
then provides any currency conversion needed (see Levine at page 
7, lines 29-33). This is the opposite of what Appellant claims. 
A currency conversion is needed in Levine because the Levine 
transaction is performed exclusively using the ATM' s currency. 
Nothing in Levine teaches or suggests any feature that would 
allow the transaction to be performed using any other currency 
than that of the ATM (such as, Appellant's claimed preferred 
currency) . The Levine system does not associate the card 
currency with the transaction, i.e., change the currency of the 
transaction from the merchant currency to the cardholder 
currency at the point of sale. If Levine permitted the 
transaction to take place in the ETC's currency, then in 
contrast to the teaching of Levine, no currency conversion would 
need to take place. 

Again, within the context of a multicurrency environment of 
the present invention, for any individual merchant, individual 
transactions may take place using any one of a number of 
different currencies. That is, Appellant's claims define an 
invention that permits a payment card transaction to take place 
between a merchant and a customer using the customer's preferred 
currency. Like Boston, Levine does not disclose such a system. 
Rather, Levine discloses a system in which transactions take 
place exclusively in the currency of the merchant. 



Consequently, the teaching of Levine does not further the 
teaching of Boesch and/or Boston with respect to these features, 
as discussed above and claims 17-22 and 31-40 are believed to be 
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allowable. Accordingly, the Board is respectfully requested to 
reconsider claims 17-22 and 31-40. 



Conclusion 



Claims 1, 3-8, 10, 12-23, and 25-40 are included in this 
Appeal . 



The rejection of claims 1, 3, 10, 12, 23, and 25 under 35 
U.S.C. 102(e) as being anticipated by Boesch is believed to be 
improper. Likewise, the rejection of claims 4-8, 13-16, and 26- 
30 under 35 U.S.C. 103(a) as being unpatentable over Boesch in 
view of Boston is believed to be improper, and the rejection of 
claims 17-22 and 31-40 under 35 U.S.C. 103(a) as being 
unpatentable over Boesch and Boston in view of Levine is 
believed to be improper. In general, the references are silent 
as to any articulated or implied motivation for the 
modifications suggested in the Office Action. In addition, the 
references are silent as to all of the features of the claimed 
invention. However, a failure to teach or suggest all of the 
claimed features, lack of a suggestion for combination, and 
hindsight are improper standards for holding claims to be 
unpatentable . 
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Appellant believes that the arguments above fully respond 
every outstanding ground of rejection and that the contested 
claims should be found allowable. 



Respectfully submitted, 




Lowell W. Gresham 
Attorney for Appellant 
Reg. No. 31,165 



Lowell W. Gresham 

5727 North Seventh Street 

Suite 409 

Phoenix, AZ 85014 
(602) 274-6996 
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Appendix A Claims on Appeal 



This Appendix is thirteen pages, including this cover page, 
and contains a clean double-spaced copy of the claims on appeal. 
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Claim 1: A data processing method performed in a data 
processing system for determining a preferred currency for 
association with a payment card transaction between a merchant 
and a payment card cardholder, said method including the steps 
of: 

obtaining the card number of the payment card; 

in said data processing system, identifying an identifier 
code from said card number; 

determining the operating currency for said identifier code 
by comparing said identifier code with entries in a table 
wherein each entry in said table contains an issuer identifier 
code or range of issuer identifier codes and a corresponding 
currency code; and 

setting the currency for association with the payment card 
transaction as the determined operating currency for the 
identifier code. 

Claim 3: A method according to claim 1, wherein the 
preferred currency is set to a default currency of the merchant 
when no operating currency can be determined for the identifier 
code . 

Claim 4: A method according to claim 1, wherein the 
cardholder is prompted as to whether the transaction is to be 
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conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency and presenting these amounts for review by 
the cardholder. 

Claim 5: A method according to claim 1, wherein at least 
one of the transaction amounts is converted to an equivalent 
amount in the preferred currency and is presented to the 
cardholder . 

Claim 6: A method according to claim 5, further comprising 
the step of presenting an exchange rate to the cardholder, said 
exchange rate corresponding to a rate between the merchant's 
currency and the preferred currency. 

Claim 7: A method according to claim 5, wherein the 
transaction details in the merchant's currency are also 
presented to the cardholder. 

Claim 8: A method according to claim 1, further comprising 
the step of initially checking to determine if the transaction 
amount exceeds a predetermined minimum level for processing in 
an alternative currency to that of the merchant's currency. 
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Claim 10: A data processing system for determining a 
preferred currency for association with a payment card 
transaction, the payment card having a card number, between a 
merchant and a payment card cardholder, said means comprising; 

means for obtaining the card number of the payment card 
from the cardholder, 

means for identifying an identifier code from said card 
number, 

means for determining the operating currency for said 
identifier code by comparing said identifier code with entries 
in a table, wherein each entry in said table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and 

means for setting the currency for association with the 
payment card transaction as the determined operating currency 
for the identifier code. 

Claim 12: A data processing system according to claim 10, 
further comprising means for setting the preferred currency to 
the default currency of the merchant when no operating currency 
can be determined for the identifier code. 

Claim 13: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
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as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising conversion 
means for converting the transaction amounts to equivalent 
amounts in the preferred currency and presenting these amounts 
for review by the cardholder. 

Claim 14: A data processing system according to claim 13, 
further comprising means for accepting an indication from the 
cardholder as to whether the transaction is to proceed in the 
preferred currency and means for permitting the transaction to 
be processed in the preferred currency if such an indication is 
received . 

Claim 15: A data processing system according to claim 10, 
further comprising conversion means for converting at least one 
of the transaction amounts to an equivalent amount in the 
preferred currency and presenting this converted amount to the 
cardholder, optionally comprising means for presenting an 
exchange rate to the cardholder, said exchange rate 
corresponding to a rate between the merchant's currency and the 
preferred currency. 

Claim 16: A data processing system according to claim 10, 
further comprising means for initially checking to determine if 
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the transaction amount exceeds a predetermined minimum level for 
processing in an alternative currency to that of the merchant's 
currency. 



Claim 17: A data processing system according to claim 10, 
wherein said data processing system is embodied in a payment 
card terminal . 



Claim 18: A data processing system according to claim 10, 
wherein said data processing system is embodied in a central 
payment router. 



Claim 19: A data processing system according to claim 10, 
wherein said data processing system is embodied in an 
authorisation host, optionally in co-operation with another 
system. 

Claim 20: A data processing system according to claim 19, 
wherein said other system is a payment card terminal or central 
payment router. 

Claim 21: A data processing system according to claim 10 
further comprising means for connecting to a node in a computer 
network . 
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Claim 22: A data processing system according to claim 21, 
wherein the card number is received via the computer network. 

Claim 23: A computer program encoding a set of computer 
instructions for use in a computing device for determining a 
preferred currency for association with a payment card 
transaction, the payment card having a card number, between a 
merchant and a payment card cardholder, comprising 

a computer code section which when executed on the 
computing device obtains the card number of the payment card 
from the cardholder, 

a computer code section which when executed on the 
computing device identifies an identifier code from said card 
number, 

a computer code section which when executed on the 
computing device determines the operating currency for said 
identifier code, by comparing said identifier code with entries 
in a table, wherein each entry in said table contains an issuer 
identifier code or range of issuer identifier codes and a 
corresponding currency code, and 

a computer code section which when executed on the 
computing device sets the currency for association with the 
payment card transaction as the determined operating currency 
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for the identifier code. 

Claim 25: A computer program according to claim 23, 
comprising a computer code section which when executed on the 
computing device sets the preferred currency to the default 
currency of the merchant when no operating currency can be 
determined for the identifier code. 

Claim 26: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including converting 
the transaction amounts to equivalent amounts in the preferred 
currency and presenting these amounts for review by the 
cardholder . 

Claim 27: A computer program according to claim 23, 
comprising a computer code section which when executed on the 
computing device converts at least one of the transaction 
amounts to an equivalent amount in the preferred currency and 
presents the converted amount to the cardholder. 

Claim 28: A computer program according to claim 27, 
comprising a code section which when executed on the computing 
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device presents an exchange rate to the cardholder, said 
exchange rate corresponding to a rate between the merchant's 
currency and the preferred currency. 

Claim 29: A computer program according to claim 27, 
comprising a computer code section which when executed on the 
computing device presents the transaction details in the 
merchant's currency to the cardholder. 

Claim 30: A computer program according to claim 23, 
comprising a code section which when executed on the computing 
device initially checks to determine if the transaction amount 
exceeds a predetermined minimum level for processing in an 
alternative currency to that of the merchant's currency. 

Claim 31: A method according to claim 1, wherein the card 
holder is prompted as to whether the transaction is to be 
conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency and presenting an exchange rate to the 
cardholder, said exchange rate corresponding to a rate between 
the merchant's currency and the preferred currency. 



Claim 32: A method according to claim 1, wherein the card 
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holder is prompted as to whether the transaction is to be 
conducted in the preferred currency, including the steps of 
converting the transaction amounts to equivalent amounts in the 
preferred currency, presenting said equivalent amounts for 
review by the cardholder, and presenting an exchange rate to the 
cardholder, said exchange rate corresponding to a rate between 
the merchant's currency and the preferred currency. 

Claim 33: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising means for 
presenting an exchange rate to the cardholder, said exchange 
rate corresponding to a rate between the merchant ' s currency and 
the preferred currency. 

Claim 34: A data processing system according to claim 10, 
further comprising prompting means for prompting the cardholder 
as to whether the transaction is to be conducted in the 
preferred currency, said prompting means comprising: 

conversion means for converting the transaction amounts to 
equivalent amounts in the preferred currency and presenting 
these amounts for review by the cardholder; and 

means for presenting an exchange rate to the cardholder, 
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said exchange rate corresponding to a rate between the 
merchant's currency and the preferred currency. 

Claim 35: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including presenting 
an exchange rate to the cardholder, said exchange rate 
corresponding to a rate between the merchant's currency and the 
preferred currency. 

Claim 36: A computer program according to claim 23, having 
a computer code section which when executed on the computing 
device prompts the cardholder as to whether the transaction is 
to be conducted in the preferred currency, including converting 
the transaction amounts to equivalent amounts in the preferred 
currency, presenting these equivalent amounts for review by the 
cardholder and presenting an exchange rate corresponding to a 
rate between the merchant's currency and the preferred currency. 

Claim 37: A method of operating a data processing system 
to conduct a financial transaction for the exchange of money 
provided by a payment card cardholder for a good or service 
provided by a merchant, said method comprising: 
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obtaining a card number from said payment card; 

identifying, in said data processing system, an identifier 
code from said card number; 

determining an operating currency for said identifier code 
by comparing said identifier code with entries in a table that 
associates issuer identifier codes with currency codes; 

indicating said operating currency as being a preferred 
currency of exchange for said financial transaction; 

receiving a cardholder reply in response to said indicating 
activity; and 

completing said financial transaction in response to said 
receiving activity. 

Claim 38: A method as claimed in claim 37 wherein: 

said cardholder reply instructs said data processing system 

to conduct said financial transaction using said preferred 

currency; and 

said completing activity completes said financial 

transaction using said preferred currency. 

Claim 39: A method as claimed in claim 38 wherein: 

said indicating activity additionally indicates a currency 

exchange rate for converting from a merchant currency to said 

preferred currency; and 
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said completing activity uses said currency exchange rate 
in completing said financial transaction. 

Claim 40: A method as claimed in claim 38 wherein said 
indicating activity additionally indicates a first amount of 
money for said financial transaction using a merchant currency 
and a second amount of money for said financial transaction 
using said preferred currency. 
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Appendix B - - Evidence 

This Appendix is one hundred and sixty- five pages, 
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Merchant-Message 


263J 


Amount 


263K 


User-Memo 


263L 


Session-Id 


263M 


Index 
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Figure 5Q 

Table Illustrating Load/Unload Response 264 



264A 


Transaction-Type 


2MB 


Transaction-Number 


264C 


Transaction-Date/Time 


264D 


Software-Severity-Code 


264E 


Software-Message 


264F 


Response-Code 


264G 


Response-Message 


264H 


Persona-ID 


2641 


Instrument- Account-Number 


264J 


Amount 


264K 


Fee 


264L 


Balance 


264M 


On-hold-balance 
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Figure 5R 

Table Illustrating Open Session Response Record 265 



265A 


Transaction-Type 


265B 


Transaction-Number 


265C 


Transaction-Date/Time 


265D 


Software-Severity-Code 


265E 


Software-Message 


265F 


Response-Code 


265G 


Response-Message 


265H 


Persona-ED 


2651 


Amount 


265J 


Key-Use-Limit 


265K 


Key-Lifetime 


265L 


Session-ID 


265M 


Session-user-description 


265N 


Fee 


2650 


Balance 


Figure 5S 

Table Illustrating Payment Request Record 266 


266A 


Merchant-ID 


266B 


Order-ID 


266C 


Amount(s) 


266D 


Credit-Cards-Accepted 


266E 


Merchant-Note 


266F 


Pay-to-URL 
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Figure 5T 

Table Illustrating Close Session Response Record 267 



267A 


Transaction-Type 


267B 


Transaction-Number 


267C 


Transction-Date/Time 


267D 


Software-Severity-Code 


267E 


Software-Message 


267F 


Response-Code 


267G 


Response-Message 


267H 


Persona-ID 


2671 


Amount 


267J 


Transaction-Log 


267K 


Fee 


Figure 5U 

Table Illustrating Record of Customer Cash Container 
Data Structure 280 


280A 


Currency 


280B 


Available-balance 


280C 


On-hold-balance 



280.1 
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300 
Merchant 



302 
Merchant 
database 







315 

Merchant application data structure 








320 

Merchant persona data structure 








330 

Merchant Instrument binding data structure 








340 

Merchant session data structure 








345 

Merchant cash container data structure 








350 

, Merchant amount data structure 








360 

Merchant sales session data structure 








370 

Merchant cash log data structure 








380 

Message template data structure 







S 0 ^ 303 ^\ 
I Merchant 1 



Figure 6A 
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Figure 6B 

Table Illustrating Record of Merchant Appliation 
Data Structure 315 



315A 


Server-100-public-key 


315B 


URL-of-server-100 


Figure 6C 

Table Illustrating Record of Customer Persona Data Structure 320 


320A 


persona-id 


320B 


email 


320C 


public-key 


320D 


autoclose-passphrase 


320E 


language 


320F 


default-name-and-address 


320G 


software-options 


320H 


private-key 


3201 


cas h-container-data 


320J 


instrument-binding-data 


320K 


autoclose-account 


320L 


agreements 


320M 


active-sessions-data 


320N 


pending-log-data 


320O 


Iransactio n-log-data 



320,1 
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Figure 6D 

Table Illustrating Record of Merchant Instrument 
Binding Data Structure 330 



330A 


instrument-number. 


330B 


instrument-description 


330C 


holder-name 


330D 


holder-address 


330E 


holder-city 


330F 


holder-country 


330G 


holder-zip-code 


330H 


holder-countiy-code 


3301 


holder-area-code 


330J 


holder-telephone 


330K 


currency 


330L 


transact-sale-flag 


330M 


transact-credit-flag 


330N 


unload-funds-flag 


330O 


load-funds-flag 


330P 


status 


330Q 


instrument-salt 


330R 


instrument-recurring-data 


330S 


agreements 
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Figure 6E 

. Table Illustrating Record of Merchant Session Data Structure 340 

340.1 



340A 


Session-ID 


340B 


Session-Key 


340C 


Session-Salt 


340D 


Currency 


340E 


Opening^Amount 


340F 


Current-Amount 


340G 


Opening-Date 


340H 


Closing-Date 


340J 


Key-Use- limit 


340K 


Key-lifetime 


Figure 6F 

Table Illustrating Record of Merchant Cash-Container-Data 
Data Structure 345 


345A 


Currency 


345B 


Available-balance 


34SC 


On-hold-balance 



U.S. Patent Feb. 9, 1999 Sheet 32 of 73 5,870 



Figure 7A 

Table Illustrating Record of Merchant Amount Data Structure 350 



350A 


Order-ID 


350B 


Amount-of-Transaction 


350C 


Flag 


Figure 7B 

Table Illustrating Record of Merchant 
Sales Session Data Structure 360 


360A 


Session-ID 


360B 


Session-Key 


360C 


Session-Salt 


360D 


Currency 


360E 


Opening-Amount 


360F 


Current-Amount 


360G 


Opening-Data 


360H 


Closing-Date 


3601 


Status 


360J 


Key-Use-limit 


360K 


Key-lifetime 


360L 


Persona-ID 
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Figure 7C 

Table Illustrating Record of Merchant Cash Log 
Data Structure 370 



370A 


True 


370B 


Status ~ 


370C 


Order-Id 

*-/•* Uvl "Ml 


370D 


f^ustnrnpr-SMQion-TO 


370E 


Custnmer-TndfiT 


370F 


On «to m etvCii rrenev 


370G 


Merchan t-Session-ID 


370H 


Merchant-Index 


3701 


Merchant-Currency 


370J 


Merchant- Amount-Req uested 


370K 


Amount-Credited 


370L 


Fees-Paid 


370M 


Result-Code 


370N 


Type 


370O 


Status 


370P 


Transaction-Number 


370Q 


Requested-Session-Duration 


370R 


Requested-Session-Count 


370S 


Session-ID 


370T 


Result-Code 
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FIGURE 7D 

Table Illustrating The Format of Sample Message 4000 



4005 


[header] 


4013A 


labell: valuel 


4013B 


label2: value2 


4017 


opaque: 


4050 


[trailer] 
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(1201 A 
Begin registration 1 
process 401 J 



\ 


r 


1202 

Request registration 
Information 



I 




1202A 
Generate public/private 
key pair 



I 



1203 

Assemble message R1 
(steps 801-819) 



I 



1209 

Update persona data 
structure 120 



No 



1204 

Transmit message R1 



1206 

Unwrap message R1 




1215 

Write error messages 
and set codes 



I 



1217 

Assemble message 
R2(steps 1001-1015) 



I 



1218 




Transmit messa 


ge R2 




1225 
End registration 
process 401 



Figure 8 
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801 >V 
Begin message \ 
assembly J 
procedure 900 



I 



802A 
Obtain labels for 
transparent section 
contents 



I 



802B 
Associate labels 
with values 



802C 

Generate DES key/IV 
pair and store In 
temporary register 



I 



804 

Retrieve RSA public key 



806 

Encrypt DES key/IV 



I 



807 

Obtain labels for opaque 
section contents 



I 



808 

Associate labels with 
value 



810 

Generate digital 
signature 



81 2A 

Add signature field to 
other opaque label-value 
pairs and encrypt 



81 2 B 
Append encrypted 
opaque to encrypted DES 
key 




815 

Append transparent 
label-value pairs 






818 

Append opaque 
label-value pair 






817 

Create and append trailer 






81 

Update Ic 
strud 


8 

>cal data 
hires 



(M9 \ 

End message \ 

assembly J 
procedure 800 



Figure 9 
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Figure 10A 
Table Illustrating The Format of Message Rl 



4205 


[header] 


4213A 


transaction: 


4213B 


date: 


4213C 


serverkey: 


4213D 


service-category: 


4217 


opaque: 


4250 


[trailer] 




Figure 10B 


Table Illustrating The Opaque Section Contents of Message Rl 


4217A 


type: 


4217B 


server-date: 


4217C 


swversion: 


4217D 


content-language: 


4217E 


default-currency: 


4217F 


requested-id: 


4217G 


email: 


4217H 


agreements: 


42171 


autoclose-passphrase: 


4217J 


pubkey; 


4217K 


signature: 
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f Begin message \ ^ 
I unwrap I ^ 
\^procedure 900^ 



901A 
Save message 
In log data 
structure 



902 
Extract 
protocol 
number 



903 
Calculates a 
checksum 







906A 




Decode 





I 




904A 
Discard 
message 



) 



907 
Retrieve RSA 
private key 



I 



909 
Decrypt DES 
key/IV pair 




910 
Store DES 
key/IV pair 



I 



Yea 



.... 911 
Decrypt opaque 
label-value pair 



Figure 11 A 




Figure 11 B 
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f 1001 

f Begin server message I 
V assembly procedure 1000 J 



1001A 
Obtain labels for 
transparent section 



i 



1001B 
Associate labels 
with values 



1002 

Obtain labels for opaque 
section contents 



i 



1005 
Associate labels 
and values 



1007 
Encrypt opaque 
section contents 



i 



1009 
Encode 



1010 
Create header 



1011 

Append transparent 
label-value pairs 



1012 
Append opaque 
label-value pair 



1013 
Create and 
append trailer 



1014 
Save message 



1015 

End server message 
assembly procedure 1000 



3^ 



Figure 12 
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FIGURE 13A 
Table Illustrating the Format of Message R2 



4305 


(header] 


4313A 


transaction: 


4313B 


date: 


4313C 


service-category: 


4317 


opaque: 


4350 


(trailer] 


FIGURE 13B 

Table Illustrating The Opaque Section Contents Of Message R2 


4317A 


type: 


4317B 


server-date: 


4317C 


requested-id: 


4317D 


response-id: 


4317E 


email: 


4317F 


response-code: 


4317G 


funds-waiting: 


4317H 


autoclose-passphrase: 


43171 


pubkey: 


4317J 


swseverity: 


4317K 


swmessage: 


4317L 


message: 
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1102 

Extract protocol number 




Yes 

i 



1106 
Decode opaque 




i 


1107 
Retrieve DES key 




i 


1108 




Decrypt opaque 






1105 
Set appropriate 
error flag 



Yes 



I 



<ii2i X 
End message unwrap I 
procedure 1 1 00 J 



Figure 14 
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Figure 15 
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FIGURE 16 A 
Table Illustrating The Format of Message BI1 



4405 


[header] 


4413A 


persona id: 


4413B 


transaction: 


4413C 


date: 


4413D 


serverkey: 


4413E 


service-category: 


4417 


opaque: 


4450 


[trailer] 
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FIGURE 16B 

Table Illustrating The Opaque Section Contents Of Message BI1 



4417A 


type: 


4417B 


server-date: 


4417C 


svwersion: 


4417D 


instrument-number: 


4417E 


instrument-type: 


4417F 


instrument-category: 


44171 


instrument-functions: 


4417J 


instrument-salt: 


4417K 


instrument-expiration-date: 


4417L 


instrument-name: 


4417M 


instrument-address: 


4417N 


instrument-city: 


44170 


instrument-state: 


4417P 


instrument-postal-code: 


4417Q 


instrument-country: 


4417R 


agreements: 


4417S 


autoclose: 


4417T 


autoclose-passphrase: 


4417U 


key: 


4417V 


signature: j 
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FIGURE 17A 
Table Illustrating The Format of Message BI4 



44.105 


[header] 


44.113A 


id: 


44.1 13 B 


transaction: 


44.113C 


date: 


44.113D 


service-category: 


44.117 


opaque: 


44.150 


[trailer] 


FIGURE 17B 

Table Illustrating The Opaque Section Contents of Message BI4 


44.117A 


type: 


44.117B 


server-date: 


44.117C 


response-code: 


44.117D 


swseverity: 


44.117E 


swmessage: 


44.117F 


instrument-number: 


44.117G 


instrument-type: 


44.117H 


instrument-salt: 


44.117J 


instrument-functions: 


44.117K 


instrument*: 


44.117L 


message: 
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(1401 
Begin load/unload J 
funds process 405 J 

ZT_ 



1401A 
Select load or unload 
operation 



I 



1402 

Display Instruments 
enabled for operation 
selected 



I 



1403 
Select Instrument 



I 



1406 

Request amount to 
load or unload 



I 



1407 

Assemble message LU1 



I 



1408 

Transmit message LU1 



.1409 

Unwrap message LU1 




1417 

Write error massage 
and set codes 



1411 

Update server persona 
data structure 120 



I 



1412 

Assemble message LU2 



I 



1412A 
Send message LU2 



I 



1413 




Unwrap messag 


je LU2 




1419 
Update local data 
structures 



Figure 18 
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FIGURE 19A 
Table Illustrating The Format of Message LU1 



4505 


[header] 


4513A 


id: 


4513B 


transaction: 


4513C 


date: 


4513D 


serverkey: 


4513E 


service-category: 


4517 


opaque: 


4550 


[trailer] 


FIGURE 19B 

Table Illustrating The Opaque Section Contents Of Message LU1 


4517A 


type: 


4517B 


server-date: 


4517C 


swversion: 


4517D 


amount: 


4517E 


instrument*: 


4517F 


key: 


4517G 


signature: 
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FIGURE 20A 
Table Illustrating The Format of Message LU2 



45.105 


[header] 


45.1 13 A 


id: 


45.1 13 B 


transaction: 


45.113C 


date: 


45.113D 


service-category: 


45.117 


opaque: 


45.150 


[trailer] 


FIGURE 20B 

Table Illustrating The Opaque Section Contents of Message LU2 


45.117A 


type: 


45.117B 


server-date: 


45.1 17C 


amount: 


45.117D 


response-code: 


45.117E 


message: 


45.117F 


swseverity: 


45.117G 


swmessage: 


45.117H 


fee: 


45.1171 


balance: 


45.117J 


session-funds: 


45.117K 


on -hold: 
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Begin open session 1 
process 407 J 



1502 
Request session 
Information 



1503 

Assemble message OS1 



I 



1507 

Compute session Id, 
session key, session 
salt and validate 
session limits 



I 



1508 
Update server 
data structures 



No 



1504 

Transmit message OS1 




1514 

Write error messages 
and set codes 



I 



1509 

Assemble message OS2 



I 



1509 A 
Transmit message OS2 



I 



1510 

Unwrap message OS2 




1512 

Invoke error processing 
procedures 



y 



1515 

Invoke error processing 
procedures 



y 



1516 
Update local data 
structures 



1517 

End create session 
process 407 



Figure 21 
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FIGURE 22A 
Table Illustrating The Format of Message OS1 



4605 


[header] 


4613 A 


id: 


4613B 


transaction: 


4613C 


date: 


4613D 


serverkey: 


4613E 


service-category: 


4617 


opaque: 


4650 


[trailer] 


FIGURE 22B 

Table Elustrating The Opaque Section Contents of Message OS1 




4617A 


type: 




4617B 


server-date: 




4617C 


swversion: 




4617D 


record-note: 




4617E 


amount: 




4617F 


key-lifetime: 




4617G 


key-use-limit: 




46I7H 


key; 




46171 


signature: 
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FIGURE 23A 
Table Illustrating The Format of Message OS2 


4705 


[header] 


4713A 


id: 


4713B 


transaction: 


4713C 


date: 


4713D 


service-category: 


4717 


opaque: 


4750 


[trailer] 


FIGURE 23B 

Table Illustrating The Opaque Section Contents of Message OS2 


4717A 


types 


4717B 


server-date: 


4717C 


response-code: 


4717d 


swseverity: 


4717E 


swmessage: 


4717F 


message: 


4717G 


key-lifetime: 


4717H 


key-use-lirait: 


47171 


amount: 


4717J 


foreign-exchange: 


4717K 


session-funds: 


4717L 


balance: 


4717M 


on-hold: 


4717N 


fee: 


47170 


session-id: 


4717P 


session-key: 


4717Q 


session-salt: 
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1701 \ 1702A 

Begin transaction/ 1 ^ Assemble 

payment process I ^ message 
409 J PR1 



1702A 




1702B 




1702C 




1702D 




1703 
Display 
Information 


Assemble 
message 




Update 
local data 




Transmit 
message 




Unwrap 
message 




PR1 




structures 




PR1 




PR1 






< 



1704B 
End payment 
process 



1 



1707A 
Assemble 
message 
CA1 





1706 
Create a 
cash session 




4 







1707B 
Update customer 
pending data 
structure 



1708 
Transmit 
message 

CA1 



Figure 24A 
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1 



1709 
Receive message 
CA1 and unwrap 




1701B 
Invoke merchant 
error processing / Yea 
procedures 



int \ 
ng J 



1711A 
Assemble 
message 
CA2 



I 



1711B 
Update merchant 
data structures 



I 



1712 
Transmit 
message 

CA2 



I 



1713A 
Receive 
message 
CA2 



I 



1713B 
Unwrap 
message 
CA2 




1716 

Write error messages 
and set codes for 
CA2 message for 

delivery to merchant 
In CA3 



1717 

Write error messages 
and set codes for 
CA1 message for 
forwarding to customer 
In CA4 



Yes 

J. 



1718A 
Assemble 
message 
CA3 



1718B 
Save copy 
ofCA3 



I 



1718C 
Transmit 
message 
CA3 




Figure 24B 
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Figure 24C 
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FIGURE 25 
Table Illustrating The Format of Message PR1 



5005 


[header] 


5013A 


type: 


5013B 


merchant-id: 


5013C 


merchant-order-id: 


5013D 


merchant-date: 


5013E 


merchant-swversion: 


5013F 


note: 


5013G 


merchant-amount: 


5013H 


accepts: 


50131 


url-pay-to: 


5013J 


url-cancel: 


5013K 


url-success: 


5013L 


url-failure: 


5013M 


merchant-signed-hash-key: 


5013N 


merchant-signed-hash: 


5013O 


merchant-amonnt2 : 


5050 


[trailer] 
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3301 

Begin message unwrap 
procedure 3300 



I 



3302 

Extract protocol number 



I 



3303 

Calculates a checksum 




3304E 
Determine message 
type 




3307 
Update local 
data structures 



3309 

End message unwrap 
procedure 3300 



3304B 
Discard 
message 



3 



3304D 

^( Execute other customer 
unwrap procedure 



-No- 



l 





3306 




Set appropriate 




error flag 


k ■ 







Figure 26 
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1822 
Obtain label* 
for transparent 
label-value pairs 



1623 
Associate labels 
with values 



1824 
Create 
CAOES Key 



1625 

Save CADES Key In 
temporary register 



1626 

Obtain labels for opaque 
label-value pairs 




f 


1627 
Associate labels 
with values 




f 


1628 

Generate auth-code 




t 


1629 

Append auth-code 


1 


f 


1630 
Encode 



1631 
Create header 




f 


1632 

Append transparent 
label-value pairs 






1633 
Append opaque 




f 


1634 
Append trailer 




f 



( 1635 
End message \ 
assembly procedure I 



Figure 27 
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FIGURE 28A 
Table Illustrating The Format of Message CA1 



5105 


[header] 


51 13 A 


type: 


5113B 


version: 


5113C 


session-id: 


5113D 


index: 


5U3E 


payee-currency: 


5113F 


note-hash: 


5113G 


payee-id: 


5113H 


order-id: 


51131 


service-category: 


5117 


opaque: 


5150 


[trailer] 


FIGURE 28B 

Table Illustrating the Opaque Section Contents of Message CAI 


5117A 


amount: 


5117B 


auth-code: 
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1610 

Begin CA DES Key \ 
generation procedure f 

16 °° y 



1611 

Calculate quantity "Q" 




1612 

Obtain Initialization 
vector 


u 



1615 

Strip parity bits form 
results of step 1614 


4 


1614 
Encrypt result of 
step 1613 









f \ 

I End CADES Key \ 
I generation procedure I 

V 1600 J 



1613 
Exclusive OR Q 
and Initialization 
vector 



I 



Figure 29 
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Figure 30 
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FIGURE 31A 
Table Illustrating The Format of Message CA2 


5205 


[header] 


5213A 




5213B 


version: 


5213C 


session-id: 


4213D 


index: 


5213E 


service-category: 


5217.1 


merchant-opaque: 


5217.2 


customer-opaque: 


5250 


[trailer] 


FIGURE 31B 

Table Illustrating The Opaque Section Contents of Message CA2 


5217.1A 


type: 


5217.1B 


version: 


5217.1C 




5217.1D 


subversion,,: 


5217.1E 


payer-session-id Q : 


5217.1F 


payer-index,,: 


5217.1G 


note-hash,,: 


5217.1H 


pay ee-id D : 


5217.11 


order-id Q : 


5217.1J 


merchant-amount.: 


5217.1K 


auth-code: 



FIGURE 31C 

Table Illustrating The Contents of Label- Value Pair 5217.2 



5217.2A 


amount: 


5217 JB 


auth-code: 
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f 3401 "N 
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V J 



I 



3402A 
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3402B 
Associate labels 
with values 



I 



3402C 
Create CA DES Keys for 
customer and merchant 



I 



34020 
Save CA DES Keys 
In temporary registers 



I 



3403 

Obtain labels for 
opaque label-value 
pairs and associate 

labels with values 



I 



3405 
Create auth-code 



I 



3406 

Append auth-code and 
encrypt using merchant 
CA DES Key 




3408 
Obtain labels for 
customer opaque 
label-value pairs and 
associate message 
labels with values 



3409 

Assemble customer 
opaque section 



I 
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Create auth-code 



3411 

Append auth-code 
to customer opaque 
section and encrypt 
using customer 
CA DES Key 
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Encode 
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Append transparent 
fields 
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Append merchant 
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FIGURE 34A 
Table Illustrating The Format of Message C A3 


5305 


[header] 


5313A 


type: 


5313B 


version: 


5313C 


session-id: 


5313D 


index: 


5313E 


service-category: 


5317.1 


merchant-opaque: 


5317.2 


customer-opaque: 


5350 


[trailer] 


FIGURE 34B 

Table Illustrating The Opaque Section Contents of Message CA3 


5317.1A 


subtype: 


5317.1B 


subversion: 


5317.1C 


response-code: 


5317.1D 


fee: 


5317.1E 


problem: 


5317.IF 


remark: 


5317.1G 


subtype,,: 


5317.1H 


subversion^: 


5317.11 


payer-session-id a : 


5317.1J 


payer-index,,: 


5317.1K 


response-code,,: 


5317.1L 


remark^ 


5317.1M 


collected-amount,,; 


5317.1N 


problem.: 


5317.10 


order-id n : 


5317.1P 


request-version: 


5317.1Q 


auth-code: 
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FIGURE 34C 

Table Elustrating The Contents of Label-Value Pair 5317.2(Message CA3) 



5317.2A 


response-code: 


53173B 


remark: 


5317.2C 


foreign exchange: 


5317.2D 


amount: 


5317.2E 


problem: 


5317.2F 


order-id: 


5317.2G 


request-version: 


5317.2H 


auth-code: 
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FIGURE 37A 
Table Illustrating The Format of Message CA4 



5405 


[header] 


5413A 


type: 


5413B 


version: 


5413C 


session-id: 


5413D 


index: 


5413F 


order-id: 


5413G 


service-category: 


5417 


opaque: 


5450 


[trailer] 


FIGURE 37B 

Table Illustrating The Opaque Section Contents of Message CA4 


5417A 


response-code: 


5417B 


remark: 


5417C 


foreign exchange: 


5417D 


amount: 


5417E 


problem: 


5417F 


order-id: 


5417G 


service-category: 


5417H 


auth-code: 
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Figure 38 
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FIGURE 39A 
Table Illustrating The Format of Message CS1 



4805 


[header] 


4813A 


id: 


4813B 


transaction: 


4813C 


date: 


4813D 


serverkey: 


4813E 


service-category: 


4817 


opaque: 


4850 


[trailer] 


FIGURE 39B 

Table Illustrating The Opaque Section Contents of Message CS1 


4817A 


type: 


4817B 


server-date: 


4817C 


swversion: 


4817D 


record-note: 


4817E 


session-id: 


4817F 


request-log: 


4817G 


key: 


4817H 


signature: 
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FIGURE 40 A 
Table Illustrating The Format of Message CS2 



4905 


[header] 


4913A 


id: 


4913B 


transaction: 


4913C 


date: 


4913D 


service-category: 


4917 


opaque: 


4950 


[trailer] 


FIGURE 40B 

Table Illustrating The Opaque Section Contents of Message CS2 


4917A 


type: 


4917B 


server-date: 


4917C 


response-code: 


4917D 


swseverity: 


4917E 


swmessage: 


4917F 


message: 


4917G 


fee: 


4917H 


amount: 
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ELECTRONIC TRANSFER SYSTEM AND puter. For Internet transactions, a proprietary card reader 

METHOD must be added to the computers of all customers and 

_ „ rnrn n „ wm , VTT mvWT ^ VT merchants who will use a particular card. 

BACKGROUND OF THE INVENTION * . . tl , 

The rehance on encryption, especially public key 

1. Field of Invention 5 encryption, whether based in software or hardware comes at 
Public key encryption with large key sizes (e.g., RSA) is a price: the greater the use of encryption, the greater the 

usually required for creating acceptable levels of security for processing effort required to decrypt messages. Where mes- 

message processing over an insecure network, such as the sage processing costs are important, such as in commercial 

Internet. The present invention relates to a system and network payment transaction, processor and hardware costs 

method for increasing the efficiency of secure message 10 can become a significant deterrent to using networks such as 

processing over such insecure networks. More specifically, the Internet for secure communications, 

the present invention relates to a system and method for The current art can only achieve acceptable security with 

reducing the level of encryption required in a network for the concomitant high cost of processor time, additional 

message exchanges. Even more specifically, the present hardware, or both. What is needed to encourage the devel- 

invention relates to processing electronic cash transactions 15 opment of insecure networks such as the Internet for com- 

in a secure manner while substantially reducing the compu- mercial use is a software-based system that offers reduced 

tational requirements for encryption. * processing costs of encrypted messages while maintaining 

2. Description of the Prior Art an acceptable level of security for the communications being 
Various methods for increasing the security of commu- transmitted 

nications over insecure networks, such as the Internet, have 

been disclosed. An insecure network does not protect mes- SUMMARY OF INVENTION 
sages from observation, interception, and manipulation. On Therefore, the present invention aims to provide a system 
the other hand, secure networks offer various means to and method for very efficient, economic and secure trans- 
reduce the opportunity for observation, interception, and/or ^ actions over the Internet, or other insecure networks. This 
manipulation of messages. provides the basis for implementing relatively small value, 

For example, channel message security schemes (such as secure payment (including small cash payments) for prod- 
secure HTTP ("S-HTTP") and Secure Socket Layer (SSL) ucts over the Internet or other insecure networks, 
protocol) are intended to create confidence in two commu- In accordance therewith, we herein disclose a method for 
nicating parties that they are who they say they are and that M securely communicating in a communication system. The 
their communications are private. SSL utilizes digitally communication system comprises a first device at a first 
signed certificates to provide authentication and security by party's location, a second device at a second party's 
heavfiy encrypting each message. S-HTTP relies on digitally location, and a server in communication therewith. The 
signed messages using a heavy encryption key to ensure me thod comprises creating a first session associated with the 
security and authentication. 35 fi^t party, wherein the first session has first use parameters 

Anumber of multi-party protocols have been proposed for for limiting the duration that said first session can be used 

credit transactions, most notably Secure Transport Technol- and a first set of data. The first use parameters and said first 

ogy (STI), Internet Keyed Payments (IKP), and Secure set of data are identifiable by the server. The method also 

Electronic Payment Protocol (SEPP). All of these comprises creating a second session associated with the 

approaches are built around a credential issuing authority ^ second party. The second session has second use parameters 

and require that both merchants and customers be authen- for limiting the duration that the second session can be used 

ticated by the credential issuing authority w hich in turn has and a second set of data. The second use parameters and said 

been authenticated by a higher authority. In STT, merchants second set of data are identifiable by the server. The method 

and customers each have two sets of RSA of keys, one to be further comprises linking a portion of the first session with 

used to sign messages and one used to encrypt and decrypt 45 a portion of the second session in the communication 

symmetrical keys. Thus, in this system, each party needs two system. The portion of the first session includes said first set 

certificates (one for each key). A merchant will have a pair 0 f data and said first use parameters and the portion of the 

of credentials for each credit card it accepts. SEPP and IKP second session includes the second set of data and the 

use RSA encryption differently; but, like STT, utilize mul- second use parameters. The method still further comprises 

tiple public key signatures and encryptions per transaction, 50 verifying the first and second parties based upon at least 

Another system has been described under the name "Net- portions of the first and second sets of data by the server, and 

Bill." While the NetBill approach is less reliant on public determining whether the first and second sessions can be 

key encryption than others, it still requires public key used based upon the first and second use parameters by the 

signatures throughout a transaction. server. When the server verifies the first and second parties 

Another approach is that of DigiCash. In the DigiCash 55 and determines that the first and second sessions can be 

model, the user creates a random number, which acts like a used, the first and second parties are assured of communi- 

serial number for a digital coin. Like the other proposed eating securely in the communication system, 

systems, DigiCash achieves its primary objective of a Another aspect of the present invention is directed to a 

secure, anonymous cash payment system by requiring heavy method for securely communicating in a communication 

reliance on modular exponentiation (which is the basis for 60 system. The communication system has a device at a user's 

other public key techniques such as RSA encryption). It also location and a server in communication therewith, and the 

requires a bank or third party to create tokens that have method comprises transmitting a request from the device to 

mtrinsic value. It is uncertain how such a system will be the server for creating a session having use parameters 

treated under banking, tax, and currency laws in the United associated therewith, encrypting a first key with a second 

States and other jurisdictions. 65 key by the server, and transmitting the encrypted first key 

Other systems, such as Mondex, implement security and the use parameters associated with the session from the 

through the use of hardware connected to the user's com- server to the device. The method also comprises receiving 



FIG. 2 depicts the general processes of the present inven- 
tion. 
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the encrypted first key and the use parameters by the device FIG. 5K depicts pending open session record 255 of 

and decrypting the encrypted first key so that the device can customer pending transaction data structure 250. 

communicate securely in the communication system by piG. 5L depicts pending close session record 256 of 

using the decrypted first key according to the use param- customer pending transaction data structure 250. 

5 FIG. 5M depicts customer log data structure 260. 

BRIEF DESCRIPTION OF DRAWINGS HG. 5N depicts persona registration/update response 

... . record 261 of customer log data structure 260. 

Representative embodiments of the present mvention will ™« ^ " . 

be described with reference to the following drawings: 5 ° depiC f ******* instrument response record 

^ - , . , « 10 262 of customer log data structure 260. 

FIG. 1 depicts the general architecture of the present CTn „ « . . , . , , 

invention depicts cash payment response record 263 of 

customer log data structure 260. 
FIG. 5Q depicts load/unload funds response record 264 of 

_^ „ . . . , , a . 4 customer log data structure 260. 

FIG. 3Amorc particularly depicts the processes shown in is m o *n j * * • , r 

pjQ 2 r FIG. 5R depicts open session response record 265 of 

^ * „„ , . f „ customer log data structure 260. 

FIG. 3B depicts the flow, of messages in the present CTr , - e , . . , ^ , r 

invention FIG * 5S depicts payment request record 266 of customer 

\ * . , . , ■ lo S data structure 260. 

nG.4Adepicts the structure of the database of the server mn c ~ . . f , . r 

computer 100 20 depicts close session response record 1 267 of 

trio at} j' * ^ ' ^ customer log data structure 260. 

FIG. 4B depicts a customer persona 120.1 of server - TT , . , , „ OA - r „ ■ 

persona data structure 120. . FIG * 5U de P lcts Mf 00 ^ 2801 of Customer cash 

, . . „ , , tamer data structure 280. 
FIG. 4C depicts the fields of cash container data 120G of £ A , 4 , _ „ ^ , , , - it _ 

pj G 4B FIG. 6A depicts the structure of the database of the 

^ merchant computer. 

FIG. 4D depicts the fields of instrument binding data xdj. ^ a u * i* j « 

120H of FIG 4B depicts a record of the merchant application data 

" ^ ~ J . * , _ structure of the database of the merchant computer. 

FIG. 4E depicts a merchant persona 120.2 of server ^ n An , . . , - . 4 . 

persona data structure 120. # 6C depicts a record of the merchant persona data 

inn An a • ♦ *u c u * u * • j 30 structure of the database of the merchant computer. 

FIG. 4F depicts the fields of cash container data L20GG 30 CTr , m , . , , , , ** . _ 

of FIG 4E depicts a record of the merchant instrument 

_ ' ' , . A , _ tJ , . - binding data structure of the database of the merchant 

Hu. 4Cj depicts the nelds or instrument binding data computer 
120HHof FIG.4E. ^ ^ . . ' 

r^rry att j • . • , „ „ FIG. 6E depicts a record of the merchant session data 

FIG. 4H depicts customer session record 130.1 of server 35 structure of the database of the merchant computer, 
session data structure 130. CTO £ „ , j * - / 

mn aia *u « u r. • ^ FIG. 6F depicts a record of the merchant cash container 

*KMI de P lcts t"» fi<*k of transaction data 130N of FIG. data stmctnie- of the database of the merchant computer. 

at i • . » . F 10 * 7A depicts a record of the merchant amount data 

FIG. 4J depicts merchant session record 130.2 of server structure of the database of the merchant computer. 

session data structure 130. 40 JJ?L t ' 

jnn +u a u r _ * , 1 , nviVT . FIG. 7B depicts a record of the merchant sales session 

FIG. 4J tnmsacUoB date 130NN of data * f ^ diUbase of ^ mcKhm ampmL 

vtr /ii „ , i « i * . FIG- 7C depicts a record of the merchant cash log data 

r' T pias a recora lw,i 01 message ^8 aata structure of the database of the merchant computer. 

HG. SA depicts the structure of the database of the 45 ™' 1° tto ' filo,ut ° f 8 Sample message - 

customer computer 200. 8 is a flow diagram illustrating registration process 

* 401 

FIG. SB depicts record 215.1 of customer application data * rt 

structure 215. 9 is sl flow diagram illustrating message assembly 

FIG. 5C depicts record 220.1 of customer persona data so V 10 ™*™* m 
structure 220. FIGS. 10A and 10B depict the format of registration 

FIG. 5D depicts record 230.1 of customer instrument message R1 ' 

binding data structure 230. FIGS. 11A and UB is a flow diagram illustrating server 

FIG. 5E depicts record 240.1 of customer active session messa S e ™ a P procedure 900. 

data structure 240. 55 FIG. 12 is a flow diagram illustrating server message 

FIG. 5F depicts customer pending log data structure 250. assembly procedure 1000. 

FIG. 5G depicts pending registration/update persona FIGS. 13A and 13B depict the format of registration 

information record 251 of customer pending transaction data message R2. 

structure 250. FIG. 14 is a flow diagram illustrating client message 

FIG. 5H depicts pending link/update instrument bmding ° unwrap procedure 1100. 

record 252 of customer pending transaction data structure FIG. 15 is a flow diagram illustrating instrument binding 

250. process 403. 

FIG. 51 depicts pending cash payment record 253 of FIGS. 16A and 16B depict the format of binding message 

customer pending transaction data structure 250. 55 BI1. 

FIG. 5 J depicts pending^ load/unload funds record 254 of FIGS. 17A and 17B depict the format of binding message 

customer pending transaction data structure 250. BI4. 
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FIG. 18 is a flow diagram illustrating the load/unload puter of an individual, merchant user 303, who provides the 

funds process 405. product to customer user 203 over the Internet 50. Merchant 

FIGS. 19A and 19B depict the format of load/onload computer 300 includes merchant database 302 and merchant 

message LU1. application software 310. Information relating to merchant 

FIGS. 20A and 20B depict the format of load/unload 5 Wl 303 fe stored merchant database 302. Merchant 

message LU2. application software 310 executes the processes of the 

FIG^lisaflowdiagrammustratingopcnsessionprocess ^eTSwing detailed description is provided for a 

single customer user 203 and a single merchant user 303, it 

FIGS. 22A and 22B depict the format of open session 10 ^ notcd ^at the present invention contemplates cpmmuni- 

message OS1. cation and transactions between both single and multiple 

FIGS. 23 A and 23B depict the format of open session customer users 203 and single and multiple merchant users 

message OS2. 303. 

FIGS. 24A, 24B and 24C depict a flow diagram illustrat- Server computer 100 communicates securely — as will be 

ing transaction/payment process 409. 15 described in detail later — with customer computer 200 and 

FIG. 25 depicb the format of payment request message merchant computer 300 over the Internet 50 to effect trans- 

PRl actions between customer user 203 and merchant user 303. 

mn *>< ^I- „ r. - n + . Server computer 100 includes server database 102 and 

T' J&ii & bating message m „ ^ m Mormation rekting t0 ^ ^ 

unwrap procedure ^ m ^ m and merchant ^ 303 is stored 

FIG. 27 depicts a flow diagram illustrating message within server database 102. Server software 110 executes the 

assembly procedure CA12. processes of the.present invention. 

FIG. 28 depicts FIGS 28Aand B depict the format of cash Communication between server computer 100, customer 

payment message CA1. computer 200 and merchant computer 300 is preferably 

FIG. 29 depicts a flow diagram illustrating CA-DES-key 25 carried out by hypertext transport protocol ("HTTP") over 

generation process 1600. the World Wide Web ("WWW") services provided on the 

FIG. 30 depicts a flow diagram -illustrating message Internet 50. Of course, other protocols and networks may be 

unwrap procedure CA1. }iscd or desired. 

FIGS. 31A. 31B and 31C depict the format of message „ n0 ; ? de Pf 15 * e S enend ^ff* performed by the 

0^2 6 30 present invention. The processes start at step 0. 

0 „ A a < • .„ . Preliminarily, setup processes are performed at step 1. In 

32A md 32B dc ? lc \ a flow daagram illustrating ^ ^ processes , customer user 203 and merchant user 

server message unwrap procedure 1660. 303 (coUe *ively "clients") are configured within database 

FIG. 33 depicts a flow diagram illustrating server message 1Q2 of server computer 100. In this manner, clients can be 

assembly procedure 3400. 35 recognized by and communicate with server computer 100. 

FIGS. 34A. .34B and 34C depict the format of message Customer database 202 and merchant database 302 are also 

CA3. configured at step 1. 

FIG. 35 depicts a flow diagram illustrating message An open session process is performed at step 2. Generally, 

unwrap procedure CA34. a session is an opportunity (or window) in which customer 

FIG. 36 depicts & flow diagram illustrating message 40 user 203 mav purchase a product from merchant user 303 

assembly procedure 3100. over the Internet 50 or in which merchant user 303 may 

FIGS. 37A and 37B depict the format of message CA4. ^vide a product to customer user 203 over the Internet 50. 

ttt^i io j * * a j< mi ^_ 4 . i Customer user 203 and merchant user 303 have their own 

HG. 38 depicts a flow diagram illustrating close session • , . . 0 £ j , - 

process 411 independent sessions. Sessions are of limited duration. This 

_„ „' , , . „ 45 duration is governed by parameters. These parameters are 

FIGS. 39A and 39B depict the format of message CS1. pre fe r ably set by customer user 203 and merchant user 303. 

FIGS. 40A and 40B depict the format of message CS2. Alternatively, server computer 100 may set such parameters. 

DFTATT Pn nPSPRTPTinM np top A transaction/payment process is performed at step 3. In 

^SSSlSl^ . this step, customer user 203 and merchant user 303 agree 

so upon a product to be provided at an agreed upon price. 

Reference is now made to FIGS. 1-40 for the purpose of Customer user 203 pays for the product with electronic cash, 

describing, in detail, the preferred embodiments of the Electronic cash is a representation of funds (real cash, credit, 

present invention. The Figures and accompanying, detailed etc.) used in the present invention. The electronic cash is 

description are not intended to limit the scope of the present received by merchant user 303 who can provide the pur- - 

invention. 55 chased product to customer user 203. Customer user 203 

I. Information And Information How may conduct business with multiple merchant users 303 

The present invention is generally depicted in FIG. 1. during a session. Customer user 203 and merchant user 303 

FIG. 1 shows three entities: server computer 100, customer are only able to transact business for the duration of sessions 

computer 200 and merchant computer 300, connected to such as those created at step 2. 

each other via the Internet 50. The connections are identified 60 A close session process may be included in the' present 

by lines 105, 205 and 305, respectively. invention at step 4. This step ends the session created at step 

Customer computer 200 represents the computer of an 2. 

individual, customer user 203, who wants to buy a product The processes performed by the present invention end at 

over the Internet 50. (A "product" includes goods, services, step 5. 

information, data, and the like.) Customer computer 200 65 Referring to FIG. 3A, the processes described above in 

includes customer database 202 and customer application steps 1 through 4 of FIG. 2 are now more particularly 

software "210. Merchant computer 300 represents the com- described. Initially, the setup processes performed at step 1 
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include download and installation process 400, registration Trie open session process described far step 2 in FIG. 2 is 

process 401, instrument binding process 403 and load/ further explained with regard to the open session process 

unload funds process 405. 407 of FIG. 3 A. When customer user 203 creates a session, 

During the download and installation process 400, cus- customer user 203 is enabled to transact business over the 
tomer user 203 and merchant user 303 each download and 5 Internet 50 with one or more merchant users 303 who have 

install a copy of client application software 153 (FIG. 1) each created their own independent sessions. (Of course, 

which preferably resides on the Internet 50. Within customer merchant users 303 may also act as customer users 203 if 

computer 200 and merchant computer 300, the copy of client they so desire.) The transaction/payment process 409 is 

application software 153 resides as customer application performed next. During this process, customer user 203 and 

software 210 and merchant application software 310, merchant user 303 may negotiate and agree upon the ele- 

respectively. (Merchant application software 310 includes ments of a transaction (e.g., a particular product and price), 

other software to enable merchant computer 300 to perform Then, merchant user 303 may request that customer user 203 

the functions described below.) Using well known pay me agreed upon price for the product. In response to the 

techniques, customer application software 210 and merchant request of merchant user 303, customer user 203 may 

application software 310 are linked to the web browser of communicate to merchant user 303 that customer user 203 
customer computer 200 and merchant computer 300, 15 accepts the agreed upon price for the product It is preferred 

respectively, and are. accessed through the browser as nec- that merchant user 303 cause information regarding the 

essary. transaction to be submitted to server computer 100 for 

Next, at registration process 401, customer user 203 and validation. If server computer 100 validates the transaction, 

merchant user 303 register with server computer 100. That electronic cash is transferred from the persona of customer 
is, "persona" for customer user 203 and merchant users 303 20 user 203 to the persona of merchant user 303. Once notified 

is created within database 102 of server computer 100. A of validation, merchant user 303 can provide the product to 

"persona" is herein defined as a collection of data relating to customer user 203. 

a specific client. Therefore, by this registration process, each At close session process 411, the session created during 

customer user 203 and merchant user 303 who has registered open session process 407 may be terminated. When cus- 
with server computer 100 has their own persona in server 25 tomer user 203 (or merchant user 303) closes the session, 

computer 100. (The details of personas will be described server computer 100 disables customer user 203 (or mer- 

later.) The right of a persona to preform certain operations chant user 303) from transacting business over the Internet 

(e.g., load funds, unload funds, submit certain messages to 50 with another merchant user 303 (or customer user 203) 

server computer 100) may be enabled or disabled on a who has an open session unless customer user 203 has other 
message or service basis. 30 open sessions. 

During the instrument binding process 403 of FIG. 3A, a Referring to FIG. 3B which depicts the flow of messages 

client (a customer user 203 or a merchant user 303) com- of the present invention, registration process 401 is carried 

municates information to server computer 100 which it uses out by customer computer 200 sending message Rl 

to establish that' the client may use a financial instrument ("Registration 1") to server computer 100. In response to 

Financial instruments may include credit cards, debit cards, 35 message Rl, server computer 100 sends message R2 

demand deposit accounts ("DDAs") or other ^ financial instru- ("Registration 2") back to customer computer 200. The 

ments. The issuer of the instrument being bound or a third information included in these registration messages will be 

party guarantor sets whatever criteria are deemed necessary described later. 

by it to determine if the client may use the instrument. For During instrument binding process 403, customer corn- 
example, a bank issuing a credit card may find sufficient that 40 purer 200 sends message BI1 ("Bind Instrument 1") to 
the client provide a five .digit postal code and his mother's server computer 100. The information in message BI1 is 
maiden name in order to use the credit card. A list of these used by server computer 100 to confirm the authority of the 
criteria may, for example, be provided to server computer binder of the instrument with the issuer of that instrument or 
100 in which case server computer 100 can communicate a third party guarantor. The confirmation process could 
with the client to establish whether the client meets these 45 augmented by the exchange of messages (herein, messages 
criteria so . that the client can use the financial instrument. BI2 and BI3) between server computer 100 and customer 

Once the client establishes that the client may use the. computer 200. Messages BI2 and BI3 would have a format 

iristrument by this process, the instrument is "bound" to or similar to that of the other messages described herein. The 

associated with the client's persona created during registra- content of message BI2 may include requests for additional 

tion process 401. Once the instrument is bound, the client so information (prompted by the issuer of the instrument) or 

can use the instrument for transactions as will be described clarification of information as required by the issuer of the 

later- instrument or the third party guarantor. For example, mes- 

Lo ad/unload funds process 405 is discussed next For sage BI2 may cause customer user 203 to be prompted for 
customer user 203,.a "bad" is the process by which funds customer user 203's mother's maiden name. Message BQ 
associated with a bound instrument are "loaded" (or 55 may contain the response of customer user 203. 
transferred) to the persona of customer user 203. In the In response to message BI1, server computer 100 sends 
persona of customer user 203, the funds are represented as message BI4 ("Bind Instrument 4") back to customer corn- 
electronic cash. For customer user 203, an "unload" is the purer 200. The information included in these binding mes- 
process by which electronic cash is "unloaded" (or sages will be described later. In the description which 
-transferred) from the persona of customer user 203 to a 60 follows, messages BI1 and BI4 are 'the operative messages 
bound instrument. For merchant user 303, an ''unload" is the for instrument binding. 

process by which electronic cash is "unloaded" from the ■ During load/unload funds process 405, customer corn- 
persona of merchant user 303 to a bound instrument. For puter 200 sends message LUI ("Load/Unload 1") to server 
merchant user 303, a "load" is the process by which funds computer 100. In response to message LUI, server computer 
associated with a bound instrument are "loaded" to the 65 100 sends message LU2 ("Load/Unload 2") back to cus- 
persona of merchant user 303. In the persona of merchant tomer computer 200. The information included in these 
user 303, the funds are represented as electronic cash. load/unload funds messages will be described later. 
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During open session process 407 customer computer 200 1. Server Persona Data Structure 120 

sends message OS1 ("Open Session 1") to server computer Server persona data structure 120 stores data relating to 

100. In response to message OS1, server computer 100 the universe of customer users 203 and merchant users 303 

sends message OS2 ("Open Session 2") back to customer who have registered with server computer 100. Referring to 

computer 200. The information included in these open s FIG. 4B » persona data structure 120 includes one or more 

session messages will be described later. customer personas 120.1. It is preferred that customer per- 

During transaction/payment process 409, merchant com- sona De recorded having fields 120A-120H. Server 

puter 300 sends message PR1 ("Payment Request 1") to Persona data structure 120 contains a customer persona 

customer computer 200. In response to message PR1, cus- 1201 for each registered customer user 203. The fields of 

tomer computer sends back message CA1 ("CAsh payment 10 CD S?^ £~ 1201 no ^ describcd - „ M ^ 

i»\ *o ™mrmw inn Aft.r r™;«i rt nr Field 120 A stores a persona id for customer user 203. The 

pai P ers0Da id identifies customer user 203. In order 

CA1 merchant computer sends message CA2 ( CAsh pay- tQ em ^ ^ m ^ 

ment 2 ) server computer 100 In response to message ; CA2 store recogm 4 ble info^n for customer user 203. For 

server computer 100 sends back message CA3 ("CAsh ^ ^ actual name and ^ dr&ss of customer user 203 

payment 3') to merchant computer 300. In response to is * not stored within server database 102. Rather, the persona 

message CA3, merchant computer 200 sends message CA4 ^ ^ used for identification. The persona id field is optional 

("CAsh payment 4") to customer computer 200. The infor- uv'*hat the information stored in public key field 120C 

mation included in these transaction/payment messages will (described below) may also be used to locate records asso- 

be described later. ciated with customer user 203. Because a persona id is 

During optional close session process 411, customer 20 shorter than a public key it is more efficient, and thus 

computer 200 sends message CS1 ("Close Session 1") to preferred, to use the persona id for this purpose. 

: server computer 100. In response to message CS1, server ' Field 120B contains an email address for customer user 

computer 100 sends message CS2 ("Close Session 2") to 203. Using the email address of field 120B, server computer 

customer computer 200. The information included in these 100 is able to send email to customer user 203 over the 

close session messages will be described later.2 25 Internet 50. 

It is noted that FIG. 3B depicts messages R1/R2, BI1/BI4, Field 120C stores an RSA public key for customer per- 

LU17LU2, OS1/OS2 and CS1/CS2 passing between cus- sona 120.1. As is more fully described below, the RSA 

tomer computer 200 and server computer 100. Merchant public key of field 120C is generated by customer applica- 

user 303 causes these same messages to flow between tion software 210. The RSA public key of field 120C is the 

merchant computer 300 and server computer 100. It follows 30 public component of an RSA public/private key pair. Both 

that merchant user 303 executes registration process 401, the RSA public and private key for a customer computer 200 

instrument binding process 403, load/unload funds process are stored in customer computer 200, as described later. In 

405, open session process 407 and close session process 411 the preferred embodiment, RSA keys are 768 bits in length, 

in the same way as customer user 203, unless otherwise This length reflects a balance between increasing security 

noted. In the case of merchant user 303, data associated with 35 (achieved using longer keys) and decreasing processing 

these processes is manipulated with regard to the merchant costs (achieved using shorter keys). As processor power 

database and merchant data structures included in server increases in the future, longer RSA keys may be used to 

computer 100. increase security without compromising system perfor- 

Thc databases and data structures used in the preferred mance. 

embodiments of the present invention are described next. 40 If the customer RSA public key is encapsulated in a 

II. Databases certificate by appropriate certification authority, the key 

Referring to FIG. 1, server computer 100, customer from the certificate is used in place of the public key and the 

computer 200, and merchant computer 300 include data- persona id field 120A is no longer optional as previously 

bases 102, 202 and 302, respectively. While the following described Certificate based systems are well known in the 

description of databases 102, 202 and 302 refer to specific 45 art and are not described. 

data structures and formats, those skilled in the art will The date that customer user 203 registered with server 

readily appreciate that such specific data structures and computer 100 is stored in field 120D. The date of field 120D 

formats are not critical to and are not considered part of the permits the rurming of promotions (e.g., if you register 

present invention. Therefore, any modifications to the data before this date, then this will happen) and assists in the 

structures and formats would be within the scope of the" so resolution of disputes. 

appended claims. Field 120E contains a preferred language of communica- 

It is preferred that values be stored in databases 202 and tion for customer user 203. 

302 when a response message is received by customer Field 120F stores an autoclose passphrase for customer 

computer 200 and merchant computer 300, respectively. user 203. The autoclose passphrase is a passphrase which 

However, where it enhances clarity, values are described as 55 allows customer user 203 to close customer persona 120.1 in 

being stored prior to the receipt of such a response message. certain circumstances as described later. 

A Server Database 102 Data 120G represents a data structure containing fields 

Server database 102 stores data enabling server computer 120G.1-120G.4, shown in FIG. 4C. Fields 120G.1-120G.4 

100 to communicate with and process transactions between store data for each cash container established by customer 

customer computer 200 and merchant computer 300. FIG. 60 user 203. Server persona data structure 120 contains a set of 

4A depicts the general structure of server database 102. fields 120G.1-120G.4 for each cash container established by 

As shown in FIG. 4 A server database 102 includes server customer user 203. The cash container stores electronic 

persona data structure 120, server session data structure 130, cash. It is contemplated that multiple cash containers can be 

message log data structure 140, message data structure 150 used, e.g., one for each currency that customer user 203 

and public key data structure 160 and application data 65 intends to transact business in. 

structure 170. Each of these data structures is now described Fields 120G.1— 120G.4 are now described in detail with 

in detail. reference to FIG. 4C. 
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Field 120G.1 stores the currency associated with the reference to field 120H.4. (The term "hash" as used in this 

amount of electronic funds stored in fields 120G.2 and/or application refers to cryptographic hashes, as opposed to 

'^no^ . i. other mathematical hashing functions such as algebraic 

Field 120GJ2 stores the available-balance of the cash hashes.) The instrument number represented by the hash is 

container. . , . . t e , , 5 preferably made more difficult to guess by concatenating the 

confer on-hold-balance of the cash fatruin J t number ^ a n ^ 

Electronic cash stored in fields U0G2 and/or 120G.3 is F™** to . swver COmp ! lter ™° b J customer computer 200 
preferably deposited into an agency account (a form of number commonly referred to as a "salt") before 

bankmgmstrumentmwmchf^^ hashm g- *strunwnt salt is stored m field 230Q of 

the benefit of the other). The account number of this agency 10 ^mer instrument binding data structure 230 as discussed 
account is stored in field 120G.4. below. The instrument hash of field 120H.9 is used to verify 

Data 120H represents a data structure containing fields mc instrument number without requiring the instrument 
120H.1-120H.28, shown in FIG. 4D. Fields number to be stored at server computer 100. This reduces the 
120H.1-120H.28 store data for instruments bound to cus- attractiveness of server computer 100 as a target for thieves 
tomer persona 120.1. Server, persona data structure 120 15 ^ scoundrels. 

contains a set of fields 120H.1-120H28 for each instrument Field 120H.10 contains an identification number of the 
bound to a customer persona 120.1. Fields 120H.1-120H.28 issuer of the bound instrument, also known as a "BIN", or 
are now described in detail with reference to FIG. 4D. bank id number. 

Field 120H.1 stores the persona id of field 120A (FIG. If the instrument being bound is to be used as autoclose 
4B). The persona id of field 120H.1 indicates the persona 20 instrument, fields 120H.11 and 120H.12 contain the name 
120.1 to which the instrument having data stored in fields and address of a holder of the bound instrument. It is 
120H.1-120H.28 is bound. preferred that this information be encrypted before being 

Field 120H.2 contains an instrument type for the bound stored. Alternatively, the instrument number could be saved 
instrument. Instrument types preferably include bank in a separate store device not connected to server computer 
accounts, debit cards and credit cards. 25 100. 

Field 120H-3 stores an instrument subtype for the bound Fields 120H.13 and 120H.14 store dates that the bound 
instrument The instrument subtype is a sub-classification of instrument was bound and was first used, respectively, 
an instrument type (e.g., "VISA" for the instrument type Field 120H.15 contains a status of a bound instrument, 
credit card' 1 )- The content of binding status field 120H.15 is dependent 

Customer user 203 may elect to activate an "autoclose" 30 upon the instrument being bound. For example, to bind a 
feature when registering its persona 120.1. The autoclose DDA, customer user 203 may be required to sign a form and 
feature permits customer user 203 to provide a passphrase authorize the operator of server computer 100 to initiate a 
(described later) to close customer persona 120.1 and to pre-notification ("pre-note") process with an automated 
unload all electronic cash associated with that persona to an clearing house ("ACH"). Before receiving the signed form 
autoclose instrument If the instrument being bound is the 35 or the response to the pre-note, server computer 100 may 
autoclose instrument, field 120H.4 contains an instrument show that the binding was "created". Upon receiving the 
number for the bound, instrument The instrument number signed form, status field 120H.15 may contain "pending 
identifies the instrument. It is preferred that the instrument pre-note". If the pre-note is sent before the signed form, field 
number be encrypted before it is stored. Alternatively, the 120H.15 may contain "pending-signature". If both have 
instrument number could be saved in a separate store device 40 been received and are acceptable, field 120H.15 may contain 
not connected to server computer 100. If the instrument . "enabled". If there were a problem with either, or if a 
being bound is not the autoclose instrument, the instrument specified time period for receiving either requirement 
number is used to compute field 120H.9 (as described later) expires, field 120H.15 may contain "disabled". Field 
and the instrument number is not stored in field 120H.4. 120H.15 may also contain "disabled" if the instrument is 

Bound instruments may have a secondary number further 45 subsequently determined not to be usable (e.g., an account 
identifying the bound instrument, for example, an American is frozen by a bank) . The status of other bound instruments 
Express CID or a US-DDA account R/T number. Such will depend on the instrument type and the steps necessary 
secondary numbers, referred herein to as instrument sub- to bind a particular type of instrument. Of course, the 
numbers, are stored in field 120H.5. prenote process may be performed on-line. 

Bank accounts are created in a single currency. The native so Field 120H.16 is a flag indicating whether the bound 
currency of a bank account instrument is stored in field instrument is enabled for sale transactions. A sale transaction 
12 °H.6. is where customer persona 120.1 is used to pay for some- 

Field 120H.7 stores one or more integers representing thing using a bound instrument directly, as in the use of a 
legal agreements. In me preferred embodiment, the operator debit card. *~ 

of server computer 100 determines what legal agreements 55 If field 120H.16 indicates that the bound instrument is 
must be agreed to by customer user 203 in order for enabled for sale transactions, a limit in customer user 203' s 
customer user 203 to use the bound instrument to perform chosen (native) currency is stored in field. 120H.17. If a 
certain operations. native currency does not exist, the sale transaction limit of 

Field 120H.8 contains an instrument prefix. The instru- 120H.17 is U.S. dollars. A special' value may be used to 
ment prefix of 120H.8 is subset of the instrument number 60 indicate that there is no sale transaction limit for the bound 
described in reference to field 120H.4. In the preferred instrument. This special value may be any value that is not 
embodiment, the instrument prefix of field 120H.8 (for within the set of acceptable values of the field. For example, 
credit cards, debit cards, and bank accounts) is the first two if the limit of field 120H.17 is expressed as a positive 
and the last four digits of the instrument number of field number, the special value could be negative one. 
12 °M' 4 - t 65 Field 120H.18 is a flag indicating whether the bound 

Field 120H.9 stores an instrument hash value, preferably instrument is enabled for credit/return transactions. A credit/ 
an MD5 hash of the instrument number described with return transaction is an operation where a merchant credits 
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customer persona 120.1 in lieu of providing the product Messages exchanged between server computer 100 and 

originally agreed to. customer computer 200 during a session includes encrypted 

If field 120H.18 indicates that the bound instrument is data. Field 130B contains an encryption key (known as a 

enabled for credit/return transactions, a limit in customer "session key"). The session key of field 130B is used by 

user 203 's chosen native currency, per credit/return trans- s server computer 100 to calculate a key to decrypt encrypted 

action is stored in field 120H.19. If a native currency does messages received from customer computer 200. 

not exist, the credit/return transaction limit of field 120H.19 Field stores a session salt, preferably 8-bytes in 

is U.S. dollars. Aspecial value, may be used to indicate that length. As will be described below, messages exchanged 

there is no credit/return transaction limit for the bound inside a session between server computer 100, customer 

instrument, as previously described. 10 com P utcr 200 ^d merchant computer 300 are not authen- 

Field 120H.20 is a flag indicating whether a bound tica u ted using digital signatures. Instead, messages 

instrument is enabled for load operations, as previously c f hanged inside a session are authenticated by knowledge 

described 7 of the session key and session salt described above. To 

If field 120H.20 indicates that the bound instrument is ^^^T"?^?^- * ? Mt 

enabled for load operations, a limit is stored in field is lw of t^^L* 1 h ?f "ft" ?^?8JS 

■nnu 91 u»a «ck t^wL*™ iw* ~p * m -rwto ->T part of tne message. Use of the session salt of field 130C 

120H.21 The load cash transaction limit of field 120H.21 ensures ^ thc hash vahies arc more xajxt 

represents a limit, m native currency. If a native currency i n the present invention, customer user 203 may frtnsact 
does not exist, the load cash transaction limit of field business in one or more currencies. Reld 130D indicates a 
120H.21 may default to U.S. dollars. Aspecial value may be denornination of currency (for example, U.S. dollars) that 
used to indicate that there is no load cash transaction limit 20 customer user 203 will use during the session, 
for the bound instrument as previously described Field 130E represents a maximum amount of electronic 

Field 120H22 is a flag mdicating whether the. bound cash (in the currency of field 130D) available to customer 
instrument is enabled for unload operations, as previously user 203 at the start of the session, 
described. Field 130F represents an amount of electronic cash (in the 

If field 120H.22 indicates that the bound instrument is 25 currency of field 130D) available to user 203 at a particular 
enabled for unload cash transactions, a limit fbr cash trans- instant during the session. The initial value of field 130F is 
actions is stored in field 120H .23. The unload cash tr ansae- the value stored in opening amount field 130E. Thereafter, 
tion limit of field 120H.23 represents a limit, in native the value of current amount of field 130F is determined by 
currency. If a native currency does not exist, the unload cash subtracting each amount spent for products during the 
transaction limit of field 120H.23 may preferably default to 30 session from the previous value of 130F. 
U.S. dollars. A special value may be used to indicate that Field 130G indicates a date and time that the session was 
there is no unload cash transaction limit for the bound created. Field 130H indicates the date and time that the 
instrument, as previously described session actually closed. 

Field 120H.24 is a flag indicating whether the bound Field 1301 represents the maximum number of times (key 
instrument is designated as the autoclose binding for cus- 35 use limit) that server computer 100 will recognize customer 
tomer persona 120.1. An autoclose binding must have its computer 200's use of the session key of field 130B 
unload cash transaction flag (field 120H.22) enabled. Field 130J represents a length of time (key lifetime) that 

Field 120H.25 stores a number of hours over which the the session key of field 130B is valid, 
sales transaction limit stored in field 120H.17 applies. : Field 130K stores the persona id of customer user 203. It 

Field 120H.26 stores a number of hours over which the 40 is through the persona id of field 130K that a session is 
credit transaction limit stored in field 120H.19 applies. associated with a persona 120.1. 

Field 120H.27 stores a number of hours over which the Field 130L stores the status of a session associated with 
load cash transaction limit stored in field 120H.21 applies. the session id in field 130A. The status is either "open" or 

Field 120H28 stores a number of hours over which the "closed", 
unload cash transaction limit stored in field 120H.23 applies. 45 Field 130M stores an optional string (memo) provided by 
Field 1201 stores legal agreements as previously customer user 203 describing the session associated with the 
described. session id in field 130A Field 130M may contain a string 

While the foregoing description of customer persona provided by customer user 203 at the opening of a session 
120.1 was set forth with respect to data relating to customer and a string provided at the close of a session, 
user 203, it is noted that a merchant user 303 has merchant 50 Transaction data 130N comprises fields 130N.1-130N.5. 
persona 1202 stored in server persona data structure 120. Fields 130N.1-130N.5, shown in FIG. 41, are maintained for 
Merchant persona 1202 is shown in FIGS. 4E, 4F, and 4G each transaction initiated by customer user 203 during the 
where fields 120AA-120HH, 120GG.1-120GG.4, and session identified by the session id in field 130A. The 
120HH.1-120HH.28 correspond to fields 120A-120H, maximum number of such transactions is equal to the 
120G.1-120G.4, and 120H.1-120H.28 of FIGS. 4B, 4C and 55 key-use limit stored in field 1301. Fields 130N.1— 130N.5 
4D * are now described in detail with reference to FIG. 41. 

2. Server Session Data Structure 130 Field 130N.1 contains the amount charged to customer 

Server session data structure 130, shown generally in FIG. user 203 for a particular transaction. 
4A, stores data associated with a session. Server session data Field 130N2 stores the session id stored in field 130A 
structure 130 is now described for customer user 203. 60 Field 130N.3 stores an order identification number 
Referring to FIG. 4H, server session data structure 130 ("order id") generated by merchant computer 300 to identify 
includes one or more customer session records 130.1. Server a particular order. 

session data structure 130 contains one record 130.1 for each Field 130N.4 stores the session id of merchant 303 from 
active session of customer user 203. which the product associated with a particular transaction as 

Server computer 100 identifies a session by a unique 65 purchased, 
session identification number ("session id"). The session id Field 130N.5 contains the index value assigned by cus- 
is stored in field 130A tomer computer 200 to a particular transaction. The index 
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value must be within the key use-limit established as set software 310 to encrypt the message. In this manner, server 

forth in field 1301. Because the transactions executed by computer 100 can find the corresponding RSA private key to 

customer persona 120.1 may not be received by server decrypt the encrypted message. 

computer 100 in the order that they are executed, the index 6- Application Data Structure 170 

value is stored in a manner, such as bit map of permitted 5 Application data structure 170 tracks existing version(s) 

index values, which allows server computer 100 to deter- or " customer application software 210 and merchant appli- 

mine if a permitted index has been used and to take cation software 310. Application data structure 170 is also 

appropriate action should that occur. used to determined whether an update to customer applica- 

While the foregoing description of server session data tion so^^e 210 or merchant application software 310 is 

structure 130, customer session record 130.1 was set forth 10 ****** necessary. For example server computer 100 

with respect to data relating to customer user 203, it is noted m *? ^ a co !f™? r COmputer 200 fftomer apph- 

that a merchant 303 user has corresponding data stored in Ca £° D 210 15 ™™* yet usable, or that the 

server session data structure 130. Such a merchant session ^^^iSS^Jnlt ^ ^ 

record 130.2 is shown in FIGS. 4J and 4K where fields rL., ctni „ hirp rtf „ lct Aato 

11n . A i^axtxt j4 c ,j ™ A -- nvr , rlij. 5 A depicts the general structure or customer data- 

15 basc 202 Corner dafcbase 202 includes customer appli- 

130rW.l-130rW.5^rrespond to fields 130N.1-130N.5. calion data structure 215, customer persona data structure 

3. Message Log Data Structure 140 220, customer instrument binding data structure 230,. cus- 
Message log data structure 140 (FIG. 4A) tracks messages tomer session data structure 240, customer pending trans- 
received and sent by server computer 100. This permits action data structure 250, customer log data structure 260, 

server computer 100 to identity duplicate messages and 20 message template data structure 270 and customer cash data 

respond accordingly. Duplicate messages are used to ensure structure 280. Each of these data structures is now described 

consistent state between a client and server computer 100 in in detail. 

the face of unpredictable communications over the Internet 1. Customer Application Data Structure 215 

50. For example, a duplicate of a valid message could be Customer application data structure 215 stores data relat- 

responded to with the original response. Server computer 25 ing to server computer 100. Referring to FIG. 5B, customer 

100 might not, however, duplicate the processing of the application data structure 215 includes record 215.1, shown 

duplicate message. A record 140.1 of message log data there in detail. 

structure 140 is now described with reference to FIG. 4L. Field 215A contains an RSA public key for server com- 

Field 140A contains the persona id included in the mes- puter 100. The RSA public key of field 215A is used by 

sage received by server computer 100. 30 customer computer 200 to encrypt data in messages sent by 

Field 140B contains the session number included in a customer computer 200 to server computer 100. 

message CA2 (described later) received by server computer Field 215B stores a uniform resource locator for ("URL") 

. 100. For all other messages received by server computer for server computer 100. The URL of field 215B is the 

100, this field is preferably null. address of server computer 100 on the world wide web of the 

Field 140C contains the transaction number included in a 35 Internet 50. 

message Rl, BI1, LU1, OS1, or CS1 (described later) While the foregoing description of customer application 

received by server computer 100. For any message CA2 data structure 215 and record 215.1 was set forth with 

received by server computer 100, this field is preferably null. respect to data relating to customer user 203, it is noted that 

Field 140D contains the index included in message CA2 a merchant user 303 has corresponding data stored in 

received by server computer 100. For all other messages 40 merchant application data structure 315, shown in FIG. 6B. 

received by server computer 100, this field is preferably null. A merchant record 315.1 is shown in FIG. 6B where fields 

Field 140E contains a hash of; or copy of, the message 315A-315B correspond to fields 215A-215B. 

received (incoming) by server computer 100 associated with 2. Customer Persona Data Structure 220 

fields 140A-140D. Customer persona data structure 220 stores data relating 

Field 140F contains a copy of a message sent by server 45 to customer user 203. Referring to FIG. 5C, customer 

computer 100 in response to the message saved in field persona data structure 220 includes record 220.1, shown 

140E. there in detail. 

4. Message Data Structure 150 Fields 220A-220C correspond to and contain the same 
Message data structure 150 (FIG. 4A) includes templates information as fields. 120A-120C (FIG. 4B). 

indicative of the format and contents of messages used in the so Field 220D stores an autoclose passphrase for customer 

present invention by type and version. For example, a user 203. The autoclose passphrase is a passphrase which 

particular message may differ between one or more sup- allows customer user 203 to close customer persona 120.1 in 

ported versions of customer application software 210 or certain circumstances as described later, 

merchant* application software 310. When a message is Field 220E contains a preferred language of communica- 

received by server computer 100, it is compared to a 55 tion for customer user 203. 

template for that message. As described later, if the message A default name and address of customer user 203 is stored 

does not conform to the template, an error message is in field 220F. The default name and aiidress of field 220F is 

returned to the sender of the message. the name and address of the individual whose customer 

5. Private Key Data Structure 160 persona 120.1 is indicated by the persona id-of field 220A 
Private key data structure 160 maintains a list of the RSA 60 The default name and address of field 220F facilitates 

public/private key pairs of server computer 100 that are used providing such information when it is requested, 

in supported versions of customer application software 210 Field 220G retains preferred customer application soft- 

or merchant application software 310. As will be described . ware 210 settings (options), for example, the communication 

later, encrypted messages sent to server computer 100 preferences (e.g., time-out range in seconds), alert prefer- 

include a pointer which informs server computer 100 which 65 ences (e.g., show alerts before submitting transactions off- 

RSA public key of server computer 100 was used by line and/or when logging on), and security preferences (e.g., 

customer application software 210 or merchant application ask for passphrase before a payment operation). 
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Field 220H stores the RSA private key for a customer out storing that information in its data structures. The 

persona 120.1. The RSA private key of field 220H is the particular label-value pairs that are contained within recur- 

complement to RSA public key of field 120C, stored in ring data depend on the type of the bound instrument and the 

, server database 102. requirements of the issuer of the instrument. For example, a 

Cash container data 2201 represents fields 280A-280C 5 credit card might require the card number, the card expira- 

shown in FIG. 5U. tion date, and the name and address of the card holder to be 

Instrument binding 220J represents fields 230A-230S returned to the server each time the card is used to toad funds 

shown in FIG. 5D. into persona 120.1. The recurring data would contain data 

Field 220K retains the autoclose account number associ- which would allow customer application software 210 to 

ated with the autoclose password stored in field 220D. io return this information in the proper label- value pair format. 

Field 220L stores one or more integers representing legal Field 230S corresponds to and stores the same informa- 

agreements. In the preferred embodiment, the operator of tion as field 120H.7 (FIG. 4D) relating to legal agreements, 

server computer 100 determines what legal agreements must While the foregoing description of customer instrument 

be agreed to by customer user 203 in order for customer user binding data structure 230 and record 2301 was set forth 

203 to create a persona. 15 with respect to data relating customer user 203, it is noted 

Active sessions data 220M represents fields 240A-240K. that a merchant user 303 has corresponding data stored in 

Pending log data.220N represents records 251-256 of merchant persona data structure 330, shownon FIG. 6D. A 

pending log data structure 250. merchant record 330.1 is shown in FIG. 6D where fields 

Transaction log data 2200 repressents records 261-267 of 330A-330S correspond to fields 230A-230S. 

transaction log data structure 260. 20 4. Customer Session Data Structure 240 . 

While the foregoing description of customer persona data Customer session data structure 240 maintains inform a - 

structure 220 and record 220.1 was set forth with respect to ^ ..tion at customer computer 200 relating to a session. Refer- 

data relating to customer user 203, it is noted that merchant ring to FIG. 5E, customer session data structure 240 includes 

user 303 has corresponding data stored in merchant persona one or more records 240.1. Customer session data structure 

data structure 320, shown in FIG. 6C. A merchant record 25 240 contains one record 240.1 for each active session of 

320.1 is shown in FIG. 6C where fields 320A-3200 corre- customer user 203. A detailed record 240.1 of customer 

spond to fields 220A-220O. session data structure 240 is shown in FIG. 5E. 

3. Customer Instrument Binding Data Structure 230 Fields 240A-240F correspond to and contain the same 

Customer instrument binding data structure 230 retains information relating to a session as fields 130A-130F (FIG. 

information at customer computer 200 regarding bound 30 4H). Field 240G contains the last index used by customer 

instruments. Referring to FIG. 5D, customer instrument computer 200 during the session. Field 240H contains the 

binding data structure 230 includes one or more records same information as field 130M. Fields 24OJ-240K contain 

230.1. Customer database 202 contains one record 230.1 for the same data as fields 1301-130J, respectively, 

each instrument bound to customer persona 120.1. A While the foregoing description of customer session data 

detailed record 230.1 of customer instrument binding data 35 structure 240 and record 240.1 was set forth with respect to 

structure 230 is shown in FIG. 5D where: data relating a customer user 203, it is noted that a merchant 

Field 230A stores the instrument number. user 303 has corresponding data stored in merchant persona 

Field 230B contains a description of the bound instru- data structure 340, shown in FIG. 6E. A merchant record 

ment. 340.1 is shown in FIG. 6E where fields 340A-340K corre- . 

Fields 230C-230J respectively represent the name, 40 spond to fields 240A-240K (FIG. 5E). 

address, city, country, postal code, country code, area code 5. Customer Pending Transaction Data Structure 250 

and telephone number of the holder of the bound instrument. Customer pending transaction data structure 250 stores 

Field 230K stores a default currency associated with the (1) data necessary to create messages sent by customer 

bound instrument computer 200 and (2) a copy of each message sent by 

Fields 230L-230O are flags indicating whether the bound 45 customer computer 200. Referring to FIG. 5F, customer 

instrument is enabled for sale transactions, credit return pending transaction data structure 250 includes the follow- 

trans actions, unload and load operations. Fields 230L-230O ing records: pending persona registration/update persona 

correspond to fields 120H.16, 120H.18, 12 OH 22 and information 251, pending link/update financial instrument 

120H20, respectively (FIG. 4D). binding 252, pending cash payment 253, pending load/ 
Field 230P contains a status of the bound iristrument. The 50 unload funds 254, pending open session record 255, and 

bmtog status of fieM230Pcorresporids to pending close session record 256. Each record 251-256 is 

of field 120H.15 of FIG. 4D. now described in detail with reference to FIGS. 5G-5L. It is 

Field 230Q stores a salt for the bound instrument. The salt preferred that a pending record 251-256 be deleted upon 

of field 230Q represents a random number generated by receipt by customer computer 200 of a response message 
customer application software 210. As previously described, 55 unless customer user 203 has indicated otherwise, 
is used by server to strengthen the result of the instrument 

hash value stored in field 120H.9. a ' Pendin g Persona Registration/Update Persona 

Field 230R stores certain information associated with a Information Record 251 

bound instrument and is referred to as "instrument recurring Pending persona registration/update persona information 
data". The recurring data is a data string which is used by 60 record 251 stores data relating to processes by which cus-v 

customer application software 210 to reconstruct a set of tomer user 203 creates customer persona 120.1. Referring to 

label-value pairs identified by server computer 100 at the FIG. 5G, record 251 is shown in detail, 

time an instrument is bound. The fields are returned to server Field 251A indicates a code which represents a type 

computer 100 by customer computer 200 during operations (transaction type) of action, being performed For example, 
that require use of the instrument associated with the recur- 65 field 251A may contain "creation" which would indicate that 

ring data. In this way, server, computer 100 may receive user 203 is creating persona 120.1. If a persona 120.1 

information regarding the instrument when necessary with- already exits and the action being performed is to change 
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something associated with that persona, field 251A may Fields 252J-252Q respectively store the street address, 

contain "modification". city, state, postal code, country, country code, area code and 

Field 251B stores a transaction number, that is, a unique telephone number of the person to whom the instrument 

number indicative of a particular action. The transaction being bound was issued. 

number of field 251B is generated by client application 5 Field 252R contains customer user 203 's selected descrip- 

software 210. Hie transaction number of field 250B allows tion of the instrument being bound, 

server computer 100 to send an associated reply message. Instrument recurring data field 252S stores information 

Because transaction numbers are unique, the transaction st ored in field 230R as relates to bound instruments, 

number of field ^251B aJso perrmts server computer 100 to Field 252T stores me type of instrument being bound, for 

determine whether a message Rl is a duplicate message. 10 ^^^^ etc 

Field 251C represents the date and time that message Rl ^ ^ randora number ^ 

was assembled and sent to server computer 100. customer computer 200. The saltof field 2S2V is used to 

Field 251D stores the version of the application software strengthen the instrument number hash mainatined at server 
210 used to assemble message Rl. As further described later, fi ^qq 

the software version number of field 25 ID is used to V -, A „ a nrr u u-f ♦ * a- ♦ #u ♦ *u 

, , . ... A - • Field 252V stores a flag which if set indicates that the 

..determine whether customer application software 210 is * , A 4 ■ tUa n f , . . , 

1 4J , , . rr instrument is the autoclose account instrument, 

outdated. *~ 

. . c - A Field 252W stores an original transaction string which is 

Field 251E contains a preferred language for customer e • * i . , ° 

„«.r in* rorr^cnAr,Hin ff t« *M ->?ftp cxtio «*\ a copy of the original message BI1 sent by customer 
user 203, corresponding to field 220E (FIG. SB). 20 200 t0 ^ x ^ mpute * 100 ■ 

Field 251F contains a preferred currency for customer 

user 203, corresponding. to field 240D (FIG. 5E). c. Pending Cash Payment Record 253 

Field 251G stores a persona id requested by customer user Pending cash payment record 253 stores data relating to 
203. It should be noted that the requested persona id of field, transactions involving cash payments. Referring to FIG. 51, 

251G may not be the same as the persona id of field 120A *5 a record 253 is shown in detail 

finally assigned to customer user 203 For example, server Field 253A ^cates a code which represents a type of 

computer 100 may reject the requested persona id of field action (transaction typc) being performed. For example, if a 

251G if it is already m use by another customer user 203. ^ opcn . ^ field 254A may ^cate ^ pay . 

Field 251H contains the email address for customer user ment" indicating that customer user 203 is sending a mes- 

203, corresponding to field 220B (FIG. 5Q. 30 sage CAI (described later). 

Field 2511 contains an autoclose passphrase, correspond- Fields 253B-253D correspond to and store the same 

ing to field 120F (FIG. 4B). information as fields 251B-251D (FIG. 5G). These fields 

Field 25U stores an original transaction string which is a relate to the transaction number, transaction date and time, 

copy of original message Rl sent from customer computer 35 and software version, respectively. 

200 to server computer 100. Field 253E contains the persona id of customer user 203, 

, _ j, _ . _ „ , ' corresponding to field 220A(FIG. 5Q. 

b. Pending LiruVUpdate Instrument Record 252 «. £ ZZT* . - \ , ' , ,„ _^ 

Field 253F stores an order identification number ( order 

Pending link/update record 252 stores data relating to id"). The order id of field 254F is generated by merchant 

processes by which customer user 203 binds an instrument 40 computer 300 to identify a particular order. 

to customer persona 120.1 or updates an existing bound Field 253G contains merchant user 303's persona id 

instrument Referring to FIG. 5H, a record 252 is shown in 120AA(FIG. 4E). 

detai1. Field 253H stores an amount of electronic cash that a 

Field 252A indicates a code which represents a type of customer user 203 is paying for - a product which is the 
action (transaction type) being performed. For example, 45 subject of the current transaction, 
field 252A may contain "link" which would indicate > flat Field 253I rovides a bcation for M tional 
user 203 is linking an mstniment to customer persona 120.1. ^ 203 &neTatcd memo mat describes to par ticular 
If the action being performed is to change something asso- transaction. 

ciated with an instrument already linked with that persona, „.,.,«, • *t itdt * u ♦ t 
field 252A may contain "update". 50 *£"53J cont ™ s ^ a merchant computer 300 

j-,. , , „ MT ^ J , to which customer user 203 wishes to direct a cash payment. 

Fields 252B-252D corre^ond to and store the same Customer application software 210 uses the URL field 253J 
itf ormauon as field 251B-251D of FIG. 5G These fields t0 ^ cash te ^ the fonn of m CAI to 
relate to the transaction number transaction date and time, merchant ^ utcr 300 for forwarding to server computer 
and software version, respectrvelyv Iqq . 

Field 252E contains tjic persona id of customer user 203, 55 Keld ^ stores ^ of ^ ^ ioil durin 

corresponding to field 220A (FIG. SB). whkh ^ c ^ 

transaction was initiated. 

Field 252F stores the number of the instrument being Field 253L stores tne index assodated with ciu^nt trans- 
bound to persona 1201. action. 

" Field 252G stores admWnal customer identification 60 FieM 253M stQres ^ string- which is 

information needed to use the instrument being bound, for a of m CA1 mX 5 oagtaBm uter 200 
example, Amencan Express card customer identification merchant computer 300, to server computer 100. 

number. <cr> Field 253N contains the URL of merchant computer 

Field 252H stores the name of the person to whom the 300 on which customer user 203 wishes to cancel a trans- . 
instrument being bound was issued; 65 act i on> Customer appHcation software 210 uses the URL 

Field 2521 stores the expiration date of the instrument field 253N to cancel transaction requests in the form of 
being bound. message CAI. 
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Field 2530 contains the URL of merchant computer 300 Field 255J stores the currency associated with the amount 

to indicate a successful cancellation of a transaction by value stored in field 255F. 

customer user 203. Customer application software 210 Fie id 255K stores an original transaction string which is 

uses the URL field 2530 to indicate a successful a ^py of messa ge OS1 sent by customer computer 200 to 

cancellation m the form of message CA4. . 5 server computer 100. 
Field 253P stores the URL of merchant computer 300 to 

indicate a failure of a transaction. Customer application £ Pending Close Session Record 256 

software 210 uses the URL field 253P to indicate a n j- , • , 

77, % ? + 7T T c 7?aa Pending close-session record 256 stores data relating to 

failure of a transaction in the form of message CA4. ^ processes * by which ^ ^ 203 closes a session. 

d. Pending LoaaVUnload Funds Record 254 Rcferric S to FIG ' 5L > a rccord 256 * * detafl " ' 

Field 256 A indicates a code which represents a type of 

Pending load/unload funds record 254 stores data relating action being performed. For example, field 256A may con- 
to transactions involving loading and unlo ading of electronic tain "close-session" which would indicate that user customer 
cash. Referring to FIG. 5J, a record 254 is shown in detail. 15 203 is closing a session. 

Field 254A indicates a code which represents a type of Fields 256B-256D correspond to and store the same 

action (transaction type) being performed. For- example, information as fields 251B-251D (FIG. 5G). These fields 

field 254A may contain "load" which would indicate that relate to the transaction number, transaction date and time, 

user customer 203 is "transferring" funds into the cash and software version, respectively, 

container field 280B of record 280.1 from the instrument 20 Field 256E contains the persona id of customer user 203, 

identified in field 254R Alternatively, field 254A may con- corresponding to field 220A (FIG. 5C). 

tain Unload" which would indicate that customer user 203 „- rT7 4 . . 4 . „ „ ' „ ™ , . 

is "transferring" electronic cash funds from cash container J^J^f e ^ r or no va ^° f 

fieid 280B to the instrument identified in field 254F. field ^ 7 ^tonninos whether customer user 203 has elected 

, , to receive a log of the transactions initiated by customer user 

Fields 2S4 ^^D nxr^nd * tor l the J™ C 25 203 during the session to be closed, 

information as fields 251B-251D (FIG. 5G). These fields c . , A Z? £ „ „ 4U . .. 

relate to the transaction number, transaction date and time, . Fie ! d ?f f 6G s ^ sl0n ' ld of me open session to be 

and software version, respectively. t^t^T^ if * 0peD 8CMOnS "° * * 

^- ij-.*^ . L ' „ ™ field 256G will be null. 

Field 254E contains the persona id of customer user 203, . *u * _* r ^ , j 

corresponding to field 220A (FIG. 5CY 30 F*ld 256H stores the text of an optional description 

„. r, ~7rr? ■ . , . , related to the session closing as entered by customer user 

Field 254F stores an account number identifying a bound 203. 

instrument from which funds are to be loaded or to which „" . . . . t . t . 

funds are to be unloaded. Field 2561 stores m fransactl0n stnn S w *ch is a 

t:« u <>*An \ c c j * i_ 1 j j ,» copy of message CS1 sent by customer computer 200 to 

Field 254G stores an amount of funds to be loaded from 35 server computer 100. 

or unloaded to a bound instrument. * ^ * r * « ~ A 

tv ,^ , , , . . , 6. Customer Log Data Structure 260 

Field 254H stores the type of account from which funds n * • . ™ _ . 4 , 

are being load or to which funds are being loaded. RttaoDg to FIG. 5A, customer log data structure 260 

_.. , . „_ J¥ . , , . maintains a copy of each message received by customer 

Field 2541 stores an original transaction string which is a computer 200. Customer log data structure 260 stores data 

copy of message LU1 sent by customer computer 200 to 40 received by 0M ^ er 20Q from 

server computer 100. m Referring to ^ customer log data structure 260 

e. Pending Open Session Record 255 mdudeS ^ reCOrds: fp^tionAipdate 

6 ^ persona information response 261, link/update financial 

Pending session record 255 stores data relating to pro- instrument binding response 262, cash payment response 

cesses by which customer user 203 creates a session. Refer- 263, load/unload funds response 264, open session response 

ring to FIG. 5K, a record 255 is shown in detail. 265 > payment request 266, and close session response 267. 

Field 255A indicates a code which represents a type of Each TGCOTd 261 ~ 267 » now described in detail with refer- 

action (transaction type) being performed. For example, ence to mGS - S ^ ( - S[J ' 

^mMy^^W which would indi- 50 a> Persoaa Rcgi strationAJpdate Response Persona 

cate that user customer 203 is creating a session. Information Record 261 

Fields 255B-255D correspond to and store the same . 

information as fields 251B-251D (FIG. 5G). These fields Persona registration/update persona information record 

relate, to the transaction number, transaction date and time, 261 storcs data rela tlng to ^ e response of server computer 
and software version, respectively. 55 100 to a request to create a customer persona 120.1 by 

Field255Econtaii 1 smepersonaidofcustomeruser203, SSH * ^ ^ * ^ " 

corresponding to field 220A (HG. 5C). , • u 

iecT? 4. \ r t / • u , u o Field 261A indicates a type of action that was requested 

m I 05 ™ am ° mit ° f elCCtr0mC C3Sh t0 ^ madC and is the same as the value of field 251A of record 251. 
available during a session. ^ p ield 261B stQres a taas&sdon hmnbcT that ^ me ^ M 

Field 255G stores a value representing the maximum the value stored in 251B. 

number of transactions (key use limit) that customer user Field 261c represents the date and time that message Rl 

203 may request during a sessioa was assembled and sent to server computer 100. 

Field 255H stores a value representing the maximum As will be discussed later, messages from customer 

amount of time (key lifetime) the session will remain open. 65 computer 200 to server computer 100 convey a code con- 
Field 2551 stores the text of an optional description of a taking the version number of the customer application 

session as entered by customer user 203. software 210 used to create the message. At server computer 
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100, each software version is associated with one of three Field 262Y stores the country of issuance of the instru- 

"status" labels: current, warning, or fatal. Server computer ment. 

100 checks the software version reported in customer's Field 262Z stores a flag which if set indicates that the 

messages and includes in its reply message one of the three instrument is the autoclose account instrument, 
possible status labels. The status label returned in message 5 

R2 is stored in software severity field 261D. A text message c. Cash Payment Response Record 263 
regarding the content of software seventy field 261D may Cash paymem ^ record 263 stores ^ rclating 
also be returned by server computer 100 and, if so, is stored transactions involving cash payments and sessions. Refer- 
in field 261E. t0 5P) a 263 is shown in detail. 

A code representing the success or failure of message Rl io pfcld 263A a type of action (transaction type) 

is returned by server computer 100 and is stored in response ^ t was requested and is the same as the value of field 253 A 

code field 261F. A text message regarding the content of the Q f ^wrf 253 

response code field L 261F, if sent by server computer 100, is Fields 263B _ 263E t0 md storc me sam e 

stored m neld Z61G. information as field 261B-261C and 261F-261G of FIG. 

Field 261H stores a persona id requested by customer user " 5^ These re iate to the transaction number, date and 

203. As .described below, if the requested persona id is in time, response code, and response- message respectively, 

use, server computer 100 will suggest, a persona id to Field 2d3F ^ perSQna id of ^ 203 , 

customer user 203. The persona l id suggested by server ^^0^ t0 field 220A(FIG. 5Q. 

computer 100 is stored in field 2611. „. , , , ^ , /(( • , 

r ^ . Jj( 20 Field 263G stores an order identification number ("order 

Field 26V contains the email address for customer user . id »y ^ order id bf fi(fld 263I ^ generated by merchant 

203 corresponding to field 220B (FIG. 5Q. computer 300 to identify a particular order. 

Field 261K contains a preferred language for customer Fie i d 263H contains a merchant user 303 persona id 

user 203, corresponding to field 220E (FIG. 5Q. 120AA 

Field 261L contains a preferred currency for customer 25 Field 2631 provides a location to store a message from 

user 203, corresponding to field 240D (FIG. 5E). merchant user 303. 

b. link/Update Response Instrument Record 262 Field 2633 storcs m amount of electronic cash that a 

customer user 203 is paying for a product which is the 

Link/update instrument record 262 stores data relating to subject of the current transaction, 

the response by server computer 100 to a request by cus- 30 pield 263K provides a location for an optional customer 

tomer user 203 to bind an instrument to customer persona user 2 q 3 generated memo 

120.1.ReferrmgtoFIG.5O,ar^ Field 2fi3L stores ^ of ^ during 

Field 262A indicates a type of action (transaction) that which the current transaction was initiated, 

was requested and is the same as the value of field 252Aof Field 263M stores ^ ^ ^^ted with the current 

record 252. transaction. 

Fields 262B-262G correspond to and store the same 

information as field 261B-261G of FIG. 5N. These fields d - LoadAJnload Funds Response Record 264 

relate to the transaction date and time, software severity Load/unload funds response record 264 stores data relat- 

code, software message, response code, and response mes- ^ mg to the response of server computer 100 to a request to 

sage respectively. load or by customer user 203. Referring to 

Field 262H contains the persona id of customer user 203^ FIG. 5Q, a record 264 is shown in detail, 

corresponding to field 220A (FIG. SC). Field 2 64A indicates a type of action (transaction type) 

Field 2621 stores the number of the instrument being that was requested and is the same as the value of field 254A 

bound to customer persona 120.1. Field 262J stores the type 45 of record 254. 

of instrument being bound, for example, VISA, American p^ife 264B-264G correspond to and store the same 

Express, etc. to customer persona 120.1. information as field 261B-261G of FIG. 5N. These fields 

Field 262K stores customer identification information relate to the transaction date and time, software severity 

needed to use the instrument being bound, for example, code, software message, response code, and response mes- 

American Express card customer identification number 50 sa g e respectively. 

<cr> * Field 264H contains the persona id of customer user 203, 

Field 262L stores the name of the customer to whom the corresponding to field 220 A (FIG. 5C). 

instrument being bound was issued Fie id 2641 stores an account number identifying a bound 

Field 262M stores the expiration date of the instrument instrument from which electronic cash is to be loaded or to 

being bound. 55 which electronic cash is to be unloaded. 

Fields 262N-262U respectively store the street address, Field 264J stores an amount of electronic cash to be 

city, state, postal code, country, country code, area code and loaded from or unloaded to a bound instrument 

telephone number of the person to whom the instrument p^ld 264K stores an amount of any fee charged by the 

being bound was issued. 6Q op6ra tion of server computer 100 to load or unload funds 

Field 262V stores the text of a description of the instru- from customer persona 120.1. 

ment being bound as entered oy customer user 203. pield 264L stores an amount equal to the available bal- 

Field 262W stores the native currency, if any associated ance - of the funds held by customer persona 120.1 as 

with an instrument which is returned by server computer deterrnined by server computer 100, corresponding to the 

100. 65 value stored in field 120G.2 (FIG. 4Q. 

Field 262X stores the name of the issuer of the instrument Field 264M stores an amount of funds which have been 

which is returned by server computer 100. loaded (or unloaded) but are not available to customer user 
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203. These funds are awaiting processing, corresponding to 
the value stored in field 120G3 (FIG. 4Q. 

e. Open Session Response Record 265 

Create session response record 265 stores data relating to 
the response of server computer 100 to a request to create a 
session by customer user 203. Referring to FIG. 5R, a record 
265 is shown in detail. 

Field 265A indicates a type of action that (transaction 
type) was requested and is the same as the value of field 
255A of record 255. 

Fields 265B-265G correspond to and store the same 
information as field 261B-261G of FIG. 5N. These fields 
relate to the transaction date and time, software severity 
code, software message, response code, and response mes- 
sage respectively. u_ 

Field 265H contains the persona id of customer user 203, 
corresponding to field 220A of FIG. 5C. 

Field 2651 stores an amount of electronic cash made 
available during a session. 

Field 265J stores a value representing the maximum 
number of transactions (key use limit) that customer user 
203 may request during a session. 

Field 265K stores a value representing the maximum 
amount of time (key lifetime) the session will remain open. 

Field 265L stores a session id number. 

Field 265M stores the text of an optional description of 
the session to be opened as entered by customer user 203. 

Field 265N stores ah amount of any fee charged by the 
operation of server computer 100 to create a session. 

Field 2650 stores the available balance remaining in the 
cash container (field 120G 2) after the value in amount field 
2651 is subtracted 

f. Payment Request Record 266 

Payment request record 266 stores data relating to a 
request from merchant user 303 for payment for the product. 
The request is in the form of a message PR1 (described later) 
which is sent by merchant computer 300 to customer com- 
puter 200. Referring to FIG. 5S, a record 266 is shown in 
detail. 

Field 266A contains a merchant user 303 persona id 
120AA 

Field 266B stores an order identification number ("order 
id"). The order id of field 266B is generated by merchant 
computer 300 to identify a particular order. 

Field 266C stores an amount of electronic funds that a 
customer user 203 is paying for the product which is the 
subject of the current transaction. 

Field 266D stores a list of credit cards accepted by 
merchant 203 for payment. 

Field 266E provides a location to store a message (note) 
from merchant user 303. 

Field 266F stores the pay-to-URL., The value of label- 
value pair 50131 is an Internet 50 uniform resource locator. 
The Internet 50 uniform resource locator of label-value pair 
50131 is the address on the Internet 50 to which customer 
computer 200 is to sends message CA1, described later. 

g. Close Session Response Record 267 

Close session response record 267 stores data relating to 
the response of server computer 100 to a request to close a 
session by customer user 203. Referring to FIG. 5T* a record 
267 is shown in detail. 
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Field 267A indicates a type of action (transaction type) 
that was requested and is the same as the value of field 256A 
of record 256. 
Fields 267B-267G correspond to and store the same 
5 information as field 261B-261G of FIG. 5N. These fields 
relate to the transaction date and time, software severity 
code, software message, response code, and response mes- 
sage respectively. - 
Field 267H contains the persona id of customer user 203, 
10 corresponding to field 220A(FIG. 5Q. 

Field 2671 stores an amount of electronic cash remaining 
in the session after the close of a session after all payments 
and fees have been deducted. 
15 Field 267J stores the transaction log returned by server 
computer 100 if requested by customer user 203 in message 
CS1. This would also indicate whether or not a transaction 
log was returned. 
Field 267K stores an amount of any fee charged by the 
20 operation of server computer 100 to close the session. 
7. Message Template Data Structure 270 
Referring to FIG. 5A, message template data structure 
270 tracks the format and contents of messages that cus- 
tomer user 203 sends and receives. A message which con- 
25 tains all the required labels with valid values (e.g., syntax, 
etc.) as determined by reference to message template data 
structure 270 will be processed even if there are extraneous 
label-value pairs. A message which does not contain all the 
required label-value pairs, or which includes labels associ- 
30 ated with invalid values as determined by reference to 
message template data structure 270 will fail as to form. 

While the foregoing description of message templates 270 
was set forth with respect to data relating a customer user 
203, it is noted that a merchant user 303 has corresponding 
35 data stored in message templates 380, shown in FIG. 6A. 
8; Cash Container Data Structure 280 
.Customer cash container data structure 280 maintains 
information at customer computer 200 relating to cash 
4Q containers. Referring to FIG. 5U, cash container data struc- 
ture 280 includes one record 280.1 for each cash container 
established by customer user 203. A detailed record 280.1 of 
customer cash container data structure 280 is shown in FIG. 
5U. 

45 Fields 280A-280C correspond to and contain the same 
information relating to a cash container as fields 
120G.1-120G3 (FIG. 4C). 

.While the foregoing description of customer cash con- 
tainer data structure 280 and record 280.1 was set forth with 
so respect to data relating a customer user 203, it is noted that 
a merchant user 303 has corresponding data stored in 
merchant cash container data structure 345, shown in FIG. 
6F. A merchant record 345.1 is shown in FIG. 6F where 
fields 345A-345C correspond to fields 280A-280C (FIG. 
55 5U). 

C. Merchant Database 305 

The database 305 of merchant computer 300 is described 
next 

FIG. 6A depicts the general structure of the merchant 
60 database 302 of merchant computer 300. FIG. 6 A, depicts 
merchant application data structure 315 (previously 
described), merchant persona data structure 320 (previously 
described), merchant instrument binding data structure 330 
(previously described), merchant session data structure 340 
65 (previously described), merchant.amount data structure 350, 
merchant sales session data structure 360, merchant cash log 
370, message template data structure 380. (previously 



5,870,473 

27 28 

described), and merchant cash container data structure 345 tion. The amount of electronic cash credited is null if the 

(previously described). Data structures 350, 360 and 370 are status of field 370B is null. 

now described. Field 370L stores an amount of electronic cash funds paid 

1. Merchant Amount Data Structure 350 - to the operator of server computer 100 for processing the 
Merchant amount data structure 350 tracks the amount of 5 current collection request (i.e., a fee). 

electronic cash merchant user 303 expects to receive from If ^ of status field 3 70B is "failure", field 370M 

customeruser203for ^ an order. Referring to FIG. 7A, record storcs a result code . ^ result ^ h ^ b mer chant 

350 is shown in detail ,. c . 4 . A J 4U 

c uienA,^^ «a a j- «. c u imp application software 310 to associate a message with the 

of HG 51 Mure reported in status field 370B. Thus, thecSde returned 

Field 350B stores an amount of electronic cash (amount 10 * ^^ 7m P rom P< merchant application software 

of transaction) corresponding to field 253H of FIG. 51. !° ? mcs«g* sach as . collection failed due to 

Field 350C is a flag indicating whether an order has been ^adequate funds. 

paid for by customer user 203. . Fields 370N-370T store data relating to sessions initiated 

2. Merchant Sales Session Data Structure 360 bv merchant computer 300 (message OS1). Those fields are 
Merchant sales session data structure 360 tracks the 15 now described in detail. 

sessions of merchant user 303. Referring to FIG. 7B, record Fi^d 370N indicates a type of action being performed. In 

360 is shown in detail this case, the type stored in field 370N is "OST.. 

Fields 360A-360D correspond to fields 340A-340D Field 370O stores a status of the current collection 

(FIG. 6E). Field 360E corresponds to field 340H (FIG. 6E). request. The status of field 370O may include "attempt", 

Fields 360F corresponds to field 340F (FIG. 6E). Fields 20 "success" or "failure". The label "attempt" will be returned 

360J-360K correspond to fields 340J-340K(FIG. 6E). Field when the request has been sent to server computer 100 but 

360G stores the date that the merchant sales session iden- no response has been received. If the request is processed by 

rifled by session id field 360Awas opened. Field 360H stores server computer 100 and the collection request is honored, 

the date that such session was closed. field 370O will contain the label "success''. If server com- 

3. Merchant Cash Log Data Structure 370 25 puter 100 denies the request, field 370O will contain the 
Merchant cash log 370 tracks electronic cash transactions label "failure" and field 370T will include a code identifying 

and session data not retained in merchant sales session data the reason for such failure. 

structure 360. More specifically, merchant cash log data Field 370P stores a transaction number, that is, a iinique 

structure 370 stores data relating to collections and sessions number indicative of a particular session initiated by mer- 

initiated by a merchant user 303. Referring to FIG. 7C, a 30 chant computer 300. 

record 370 is shown in detail. Field 370Q stores a merchant user 303's requested 

Fields 370A-370M store data relating to collection mes- amount of time that the current session should last (i.e., 

sages CA2 submitted by merchant computer 300 to server requested session duration). 

computer 100. Those fields are now described in detail. Field 370R stores a merchant user 303,'s requested num- 

Field 370A indicates a type of action being performed. In 35 ber of times that the session key of field 340J can be used 

this case, the type stored in field 370A is "collection". (i.e., requested session court). 

Field 370B stores a status of the current collection If the status of field 370O is "success", field 370S stores 

request. The status of field 370B may include "attempt", a session id for merchant computer 300 for the current 

"success" or "failure". The label "attempt" will be returned session. 

when the request has been sent to server computer 100 but 40 - If the content of status field 370O is "failure", -field 370T 

no response has been received. If the request is processed by stores a result code. The result code is used by merchant 

server computer 100 and the collection request is honored, application software 310 to associate a message with the 

field 370B will contain the label "success". If server com* Mure reported in status field 370T. 

puter 100 denies the request, field 370B will contain , the HI. General Information 

label "failure" and field 370M will include a code identify- 45 The preferred format of messages used in the present 

ing the reason for such failure. invention is now described. 

Field 370C stores an order identification number ("order Due to the nature of the Internet 50, the present invention 

id"). The order id of field 370A is generated by merchant uses a message transmission independent mechanism so that 

computer 300 to identify a particular order. messages can be transmitted using several different proto- 

Field 370D stores the session id of field 240A used by so cols. These protocols may include e-mail (simple mail 

customer computer 200 in the current collection request. transport protocol) and world wide web (hyper text transport 

Field 370E stores the index of field 240G used by cus- protocol or other protocols, such as remote procedure pro- 

tomer computer 200 in the current collection request. to col (RPQ). Therefore, messages used in the present inven- 

Field 370F stores the currency of field 240D used by tion have a particular and preferred format that is not specific 

customer computer 200 in the current collection request. 55 to the transport protocol. The particular and preferred format 

Field 370G stores the session id of field 340A used by is based on RFC 822, which is well known in the art and 

merchant computer 300 in the current collection request therefore, only briefly described. 

Field 370H stores the index of label-value pair 5213D FIG. 7D depicts the format of a sample message 4000. 

used by merchant computer 300 in the current collection Sample message 4000 includes header 4005, body 4010 and 

request. 60 trailer 4050. Body 4010 includes transparent (unencrypted) 

Field 3701 stores the currency of field 340D used by label-value pairs 4013A, 4013B, etc. and may include 

merchant computer 300 in the current collection request. opaque (encrypted) label- value pair 4017. (Label-value pairs 

Field 370J stores an amount of electronic cash funds consist of a label and data relating to the label, separated by 

requested to be paid to merchant user 303 in the current . a label terminator, for example, "name: Brian".) 

collection request. 65 Header 4005 defines the start of sample message 4000. 

Field 370K stores an amount of electronic cash credited to Header 4005 may include a system identifier, for example, 

merchant cash container field 345B for the current collec- "CyberCash" (the assignee of the present invention) and a 
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number of the message protocol ("protocol number") in key of server computer 100 is stored in field 215A of . 

which sample message 4000 was assembled. customer application data structure 215. Merchant computer 

Transparent label-value pairs 4013 A, 4013B, etc. include 300 obtains a copy of user application software 153 in the 
any clear (non-encrypted) text associated with sample mes- same manner as customer user 203 using download and 

sage 4000. Encryption and decryption are described below. 5 installation process 400. In such case, user application 

Opaque label-value pair 4017 includes the label software 153 resides on merchant computer 300 as a com- 

"opaque". The value of opaque label-value pair 4017 is a ponent of merchant application software 310 and an RSA 

block of encrypted data. The value of opaque label-value public key of server computer 100 is stored in field 315A of 

pair 4017 includes a predetermined set of label-value pairs merchant application data structure 315. 

encrypted with a DES key. After encryption, the value is 10 B. Registration Process 401 

preferably base-64 encoded. The predetermined set of label- FIG. 8 depicts a flow diagram illustrating registration 

value pairs is referred to herein as the "opaque section process 401 which begins at step 1201. 

contents'* of sample message 4000. For request messages At step 1202, customer application software 210 prompts 

sent outside of a session (Rl, BI1, LU1 and CS1), the value or requests customer user 203 to enter information relating 

of opaque label-value pair 4017 begins with that DES key, is to customer user 203. This information will be included in 

RSA encrypted under a public RSA key of server computer message Rl sent to server computer 100 and will become 

100. RSA encryption is computationally expensive. For partial customer persona 120.1. In the preferred 

reply messages (R2, BI4, LU2, OS2 and CS2) and messages embodiment, customer user 203 enters a preferred language 

inside a session (CA1, CA2, CA3 and CA4), no additional of communication, a currency in which transactions will be 

information, beyond the opaque section contents, is required 20 processed, a requested persona id, an email address and an 

m the value of opaque label-value pair 4017, thus avoiding autoclose passphrase. 

the expense of RSA encryption. The opaque section contents At step 1202A, customer application software 210 gen- 
varies in length and represents data encrypted with the DES e rates an RSA public/private key pair for customer computer 
key used. 200. The RSA public key is stored in field 220C of customer 
Trailer 4050 closes sample message 4000. Trailer 4050 25 persona data structure 220 (FIG. 5C). Hie RSA private key 
preferably includes a transmission checksum. It is preferred is stored in field 220H of customer persona data structure 
that the transmission checksum of field 4050D be an MD5 220 (FIG. 5Q. 

hash performed on all printable characters in header 4005 At step 1203, message Rl is assembled in accordance 

and those appearing in body 4010. Thus, all white space, with message assembly procedure 800, depicted in FIG. 9. 

including new-lines, spaces, tabs, carriage returns, etc. are 30 Message Rl will be sent from customer computer 200 to 

omitted from the checksum hash. In this manner, the cor- server computer 100 and will include the information 

rectness of the message transmission can be checked while entered by customer user 203 at step 1202. Message assem- 

avoiding sensitivity to gateways or processing that might, bly procedure 800 is now described with reference to FIG. 

for example, change the line terminator sequence or convert 9. 

tabs to spaces. 35 Message assembly procedure 800 begins a step 801. Steps 

Encryption and decryption techniques used in the present 802A-802B create transparent label-value pairs 

invention are now described. 4213A-4213D of message Rl, shown in FIG. 10A Steps 

The present invention preferably uses both RSA and DES 802O813 create opaque label-value pair 4217 of message 

methods for data encryption and decryption. Such methods Rl, based upon the opaque section contents of message Rl, 

areweUlmownmmeart.RSAisMlydescnT)edinU.S.Pat. 40 shown in FIG. 10B. Steps 814-^817 assemble header 4205, 

No. 4,405,829. The present invention preferably relies on transparent label-value pairs 4213A-4213D, opaque label- 

768-bit RSA keys reflecting a balance between concerns value pair 4217 and trailer 4250 of message Rl. 

relating to security, execution time, and export control. The At step 802A, customer application software 210 accesses 

size of the RSAkey may change as high-end computers with message template data structure 270 (FIG. 5A) to obtain a 

fast processing speeds become more prevalent in customer 45 list of labels, which, when matched up with associated 

installations and the export requirements are relaxed. As is ' values, make up transparent label-value pairs 4213A-4213C 

known to those skilled in the art, other public/private asym- of message Rl. At step 802B, values are associated with 

metric key systems (such as Rabin, and ElGamal) could be each label as follows: 

used in the current invention for authentication purposes. Label-value pair 4213A has the label "transaction". The 

In the present invention, digital signatures are used to so value of field 4213Ais a transaction number, generated by 

authenticate information. The details of digital signatures client software 210, which uniquely identifies message Rl. 

are widely discussed in computer security literature. The The value of label-value pair 4213A allows server computer 

present invention utilizes two methods for authentication: 100, upon receipt of message Rl, (1) to send an associated 

RSA/MD5 digital signatures and knowledge of shared infor- reply message R2, described Iater,-.and (2) to determine if 
mation (e.g., a salt value and/or a key value). 55 message Rl is a duplicate message (i.e., already received by 

As mentioned above, the present invention also depends server computer 100). The value associated with label-value 

on hashing hashing of data. A has preferably is calculated pair 4213A is stored in field 251B of pending persona 

using the well-known MD5 algorithm which is described in registration/update persona information record 251 (FIG. 

, Internet publication RFC 1321, applied to a "synthetic 5G). 
message". * 60 Label-value pair 4213B has the label "date". The value of " 

If a label-value pair is specified in a hash input, but is not \ label-value pair 4213B indicates the date and time that 

present in a message, the label and label terminator are message Rl was assembled and sent to server computer 100, 

preferably omitted from the hash. according to the clock of customer computer 200. The value 

IV. Processes of the Present Invention associated with label-value pair 4213B is stored in field 
A Download And Installation Process 400 65 251C. 

During the download and installation process 400 as Label-value pair 4213C has the label "serverkey". As 

previously described with respect to FIG. 3 A, an RSA public described below, a DES key/IV pair used by customer 
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203. These funds are awaiting processing, corresponding to Field 267A indicates a type of action (transaction type) 

the value stored in field 120G3 (FIG. 4C). that was requested and is the same as the value of field 256A 

of record 256. - 
Fields 267B-267G correspond to and store the same 

Create session response record 265 stores data relating to 5 information as field 261B-261G of FIG. 5N. These fields 

the response of server computer 100 to a request to create a relate to the transaction date and time, software severity 

session by customer user 203. Referring to FIG. 5R, a record code, software message, response code, and response mes- 

265 is shown in detail. sage respectively. 

Field 265A indicates a type of action that (transaction Field 267H contains the persona id of customer user 203, 

type) was requested and is the same as the value of field 10 corresponding to field 220A (FIG. 5Q. 

255A of record 255. ^671 stores an amount of electronic cash remaining 

Fields 265B-265G correspond to and store' the same in the session after the close of a session after all payments 

information as field 261B-261G of FIG. 5N. These fields and fees have been deducted. 

relate to the transaction date and time, software severity 15 Field 2 67J stores the transaction log returned by server 

code, software message, response code, and response mes- computer 100 if requested by customer user 203 in message 

sage respectively. ; w f . q$i ^ indicate whether or not a transaction 

Field 265H contains the persona id of customer user 203, log was returned, 

corresponding to field 220A of FIG. 5C Fie l d 2 67K stores an amount of any fee charged by the 

Field 2651 stores an amount of electronic cash made 20 operation of server computer 100 to close the session, 

available during a session. 7. Message Template Data Structure 270 

Field 265J stores a value representing the maximum Referring to FIG. 5A, message template data structure 
number of transactions (key use limit) that customer user 270 tracks the format and contents of messages that cus- 
203 may request during a session. tomer user 203 sends and receives. A message which con- 
Field 265K stores a value representing the maximum 25 tains all the required labels with valid values (e.g., syntax, 
amount of time (key lifetime) the session will remain open. etc.) as determined by reference to message template data 
Field 265L stores a session id number. structure 270 will be processed even if there are extraneous 
Field 265M stores the text of an optional description of label-value pairs. A message which does not contain all the 
the session to be opened as entered by customer user 203. required label-value pairs, or which includes labels associ- 
Field 265N stores an amount of any fee charged by the 3 ° ated ^ mvalM vakes ^ determined by reference to 
operation of server computer 100 to create a session. . messa S e template data structure 270 will fail as to form. 

Field 2650 stores the available balance remaining in the WMe to foregoing description of message templates 270 

cash container (field 120G.2) after the value in amount field ^ fortn ^ res P ect 10 data relating a customer user 

2651 is subtracted. 35 xt 15 note d mal a merchant user 303 has corresponding 

data stored in message templates 380, shown in FIG. 6A 

f. Payment Request Record 266 8. Cash Container Data Structure 280 

Payment request record 266 stores data relating to a Customer cash container data structure 280 maintains 

request from merchant user 303 for payment foMhe product. information at customer computer 200 relating to cash 

The request is in the form of a message PR1 (described later) 40 containers. Referring to FIG. 5U, cash container data struc- 

which is sent by merchant computer 300 to customer com- tuxe ^80 includes one record 280.1 for each cash container , 

puter 200. Referring to FIG. 5S, a record 266 is shown in established by customer user 203. A detailed record280.1 of 

detail. customer cash container data structure 280 is shown in FIG. 

Field 266A contains a merchant user 303 persona id 5U ' 
120AA 45 Fields 280A-280C correspond to and contain the same 

Field 266B stores an order identification number ("order information relating to a cash container as fields 
id"). The order id of field 266B is generated by merchant 120G.1-120G3 (FIG. 4Q. 

computer 300 to identify a particular order. While the foregoing description of customer cash con- 

Field 266C stores an amount of electronic funds that a data stmcture 280 md record 2801 was set forth with 

customer user 203 is paying for the product which is the 50 respect to data relatin S a customer ^ it is noted that 
subject of the current transaction. a merchant USCT 303 ^ corresponding data stored in 

Field 266D stores a list of credit cards accepted by ~ T f mt c f ^'^J* ^ 

merchant 203 for payment. . * fF^g^g™* 3451 * S «°™?™ G J*^ 

tr u * j 1 ±1 4. t. > fields 345A-345C correspond to fields 280A-280C (FIG. 

Field 266E provides a location to store a message (note) 55 . 

from merchant user 303. c Merchant Database 305 

Field 266F stores the pay-to-URL. The value of label- The database 305 of merchant computer 300 is described 

value pair 50131 is an Internet 50 uniform resource locator. next. 

The Internet 50 uniform resource locator of label-value pair FIG. 6A depicts the general structure of the merchant 

50131 is the address on the Internet 50 to which customer 60 database 302 of merchant computer 300. FIG. 6A, depicts 

computer 200 is to sends message CA1, described later merchant application data structure 315 (previously 

g. Close Session Response Record 267 Jr*?^' ™ X ^ Dt 320 

. described), merchant instrument binding data structure 330 

Close session response record 267 stores data relating to (previously described), merchant session data structure 340 

the response of server computer 100 to a request to close a 65 (previously described), merchant amount data structure 350, 

session by customer user 203. Referring to FIG. 5T* a record merchant sales session data structure 360, merchant cash log 

267 is shown in detail. 370, message template data structure 380 (previously 
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described), and merchant cash container data structure 345 tion. The amount of electronic cash credited is null if the 

(previously described). Data structures 350, 360 and 370 are status of field 370B is null. 

now described. ^ Field 370Lstores an amount of electronic cash funds paid 

1 Merchant Amount Data Structure 350 to the operator of server computer 100 for processing the 

Merchant amount data stmcture >350 tracks the amount of 5 current coUection request (i.e.f a fee). 

f^,,^nTfo^ t T if C?e ? SrT ^ H «» content of status field 370B L "failure", field 370M 

customer user 203 for an order. Referring to FIG. 7 A, record „ j„ n. n j • j i! u * 

350 is shown in detail. stor ^ a . result ^ result ^ 15 ^ ^ mcrc ^ 

Field350Astoresanorderia; C orresp<)ndingtorieId253F * PP hcatl011 software 31 0 to annate a message with the 

of FIG 51 Mure reported in status field 370B. Thus, the code returned 

Field 350B stores an amount of electronic cash (amount 10 m ^ W 370M 00111(1 P 10 ^ 1 merchant application software 

of transaction) corresponding to field 253H of FIG. 51. t0 ^ky a message such as ."coUection failed due to 

Field 350C is a flag indicating whether an order has been inadequate funds." 

paid for by customer user 203. Fields 370N-370T store data relating to sessions initiated 

2. Merchant Sales Session Data Structure 360 bv merchant computer 300 (message OS1). Those fields are 
Merchant sales session data structure 360 tracks the 15 now described in detail. 

sessions of merchant user 303. Referring to FIG. 7B, record Field 370N indicates a" type of action being performed. In 

360 is shown in detaiL this case, the type stored in field 370N is "OST. 

Fields 360A-360D correspond to fields 340A-340D Field 370O stores a status of the current collection 

(FIG. 6E). Field 360E corresponds to field 340H (FIG. 6E). request. The status of field 3700 may include "attempt", 

Fields 360F corresponds to field 340F (FIG. 6E). Fields 20 "success" or "failure". The label "attempt" will be returned 

360J-360Kcorrespond to fields 340J-340K (FIG. 6E). Field when the request has been sent to server computer 100 but 

360G stores the date that the merchant sales session iden- no response has been received. If the request is processed by 

tified by session id field 360A was opened. Field 360H stores server computer 100 and the collection request is honored, 

the date that such session was closed. field 370O will contain the label "success". If server com- 

3. Merchant Cash Log Data Structure 370 25 puter 100 denies the request, field 370O will contain the 
Merchant cash log 370 tracks electronic cash transactions label "failure" and field 370T will include a code Mentifying 

and session data not retained in merchant sales session data the reason for such failure. 

structure 360. More specifically, merchant cash log data Field 370P stores a transaction number, that is, a unique 

structure 370 stores data relating to collections and sessions number indicative of a particular session initiated by mer- 

initiated by a merchant user 303. Referring to FIG. 7C, a 30 chant computer 300. 

record 370 is shown in detail. Field 370Q stores a merchant user 303's requested 

Fields 370A-370M store data relating to collection mes- amount of time that the current session should last (i.e., 

sages CA2 submitted by merchant computer 300 to server requested session duration). 

computer 100. Those fields are now described in detaiL . Field 370R stores a merchant user 303's requested num- 

Field 370A indicates a type of action being performed. In 35 ber of times that the session key of field 340J can be used 

this case, the type stored in field 370A is "collection". (i.e., requested session court). 

Field 370B stores a status of the- current collection If the status of field 3700 is "success", .field 370S stores 

request. The status of field 370B may include "attempt", a session id for merchant computer 300 for the current 

"success" or "failure". The label "attempt" will be returned session. 

when the request has been sent to server computer 100 but 40 If the content of status field 370O is "failure", field 370T 

no response has been received. If the request is processed by stores a result code. The result code is used by merchant 

server computer 100 and the collection request is honored, application software 310 to associate a message with the 

field 370B will contain the label "success". If server com* failure reported in status field 370T. 

puter 100 denies the request, field 370B will contain the III. General Information 

label "failure" and field 370M will include a code identify- 45. The preferred format of messages used in the present 

ing the reason for such failure. invention is now described. 

Field 370C stores an order identification number ("order Due to the nature of the Internet 50, the present invention 

id"). The order id of field 370A is generated by merchant uses a message transmission independent mechanism so that 

computer 300 to identify a particular order. messages can be transmitted using several different proto- 

Field 370D stores the session id of field 240A used by 50 cols. These protocols may include e-mail (simple mail 

customer computer 200 in the current collection request transport protocol) and world wide web (hyper text transport 

Field 370E stores the index of field 240G used by cus- protocol or other protocols, such as remote procedure pro- 

tomer computer 200 in the current collection request. tocol (RPQ). Therefore, messages used in the present inven- 

Field 370F stores the currency of field 240D used by tion have a particular and preferred format thatis not specific 

customer computer 200 in the current collection request 55 to the transport protocol. The particular and preferred format 

Field 370G stores the session id of field 340A used by is based on RFC 822, which is well known in the art and 

merchant computer 300 in the current collection request. therefore, only briefly described. 

Field 370H stores the index of label-value pair 5213D FIG. 7D depicts the format of a sample message 4000. 

used by merchant computer 300 in the current collection Sample message 4000 includes header 4005, body 4010 and 

request. . 60 trailer 4050. Body 4010 includes transparent (unencrypted) 

Field 3701 stores -the currency of field 340D used by label-value pairs 4013A, 4013B, etc. and may include 

merchant computer 300 in the current collection request. . opaque (encrypted) label-value pair 4017. (Label-value pairs 

Field 370J stores an amount of electronic cash funds consist of a label and data relating to the label, separated by 
requested to be paid to merchant user 303 in the current . a label terminator, for example, "name: Brian".) 

collection request 65 Header 4005 defines the start of sample message 4000. 

Field 370K stores an amount of electronic cash credited to Header 4005 may include a system identifier, for example, 

merchant cash container field 345B for the current collec- "CyberCash" (the assignee of the present invention) and a 
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number of the message protocol ("protocol number 11 ) in key. of server computer 100 is stored in field 215 A of 

which sample message 4€00 was assembled. customer application data structure 215. Merchant computer 

Transparent label-value pairs 4013A, 4013B, etc. include 300 obtains a copy of user application software 153 in the 

any clear (non-encrypted) text associated with sample mes- same manner as customer user 203 using download and 

sage 4000. Encryption and decryption are described below. 5 installation process 400. In such case, user application 

Opaque label-value pair 4017 includes the label software 153 resides on merchant computer 300 as a com- 

"opaque". The value of opaque label-value pair 4017 is a ponent of merchant application software 310 and an RSA 

block of encrypted data. The value of opaque label-value public key of server computer 100 is stored in field 315Aof 

pair 4017 includes a predetermined set of label- value pairs merchant application data structure 315. 

encrypted with a DES key. After encryption, the value is 10 B. Registration Process 401 

preferably base-64 encoded. The predetermined set of label- FIG. 8 depicts a flow diagram illustrating registration 

value pairs is referred to herein as the . "opaque section process 401 which begins at step 1201. 

contents" of sample message 4000. For request messages At step 1202, customer application software 210 prompts 

sent outside of a session (Rl, BI1, LU1 and CS1), the value or requests customer user 203 to enter information relating 

of opaque label-value pair 4017 begins with that DES key, is to customer user 203. This information will be included in 

RSA encrypted under a public RSA key of server computer message Rl sent to server computer 100 and will become 

100. RSA encryption is computationally expensive. For part -ef customer persona 120.1. In the preferred 

reply messages (R2, BI4, LU2, OS2 and CS2) and messages embodiment, customer user 203 enters a preferred language 

inside a session (CA1, CA2, CA3 and CA4), no additional of communication, a currency in which transactions will be 

information, beyond the opaque section contents, is required 20 processed, a requested persona id, an email address and an 

'in the value of opaque label-value pair 4017, thus avoiding autdclose passphrase. 

the expense of RSA encryption. The opaque section contents At step 1202A, customer application software 210 gen- 
varies in length and represents data encrypted with the DES e rates an RSApublic/private key pair for customer computer 
key used. 200. The RSA public key is stored in field 220C of customer 
Trailer 4050 closes sample message 4000. Trailer 4050 25 persona data structure 220 (FIG. 5C). The RSA private key 
preferably includes a transmission checksum. It is preferred is stored in field 220H of customer persona data structure 
that the transmission checksum of field 4050D be an MD5 220 (FIG. 5Q. 

hash performed on all printable characters in header 4005 At step 1203, message Rl is assembled in accordance 

and those appearing in body 4010. Thus, all white space, with message assembly procedure 800, depicted in FIG. 9. 

including new-lines, spaces, tabs, carriage returns, etc. are 30 Message Rl will be sent from customer computer 200 to 

omitted from the checksum hash. In this manner, the cor- server computer 100 and will include the' information 

rectness of the message transmission can be checked while entered by customer user 203 at step 1202. Message assem- 

avoiding sensitivity to gateways or processing that might, bly procedure 800 is now described with reference to FIG. 

for example, change the line terminator sequence or convert 9. 

tabs to spaces. 35 Message assembly procedure 800 begins a step 801. Steps 

Encryption and decryption techniques used in the present 802A-802B create transparent label-value pairs 

invention are now described. 4213A-4213D of message Rl, shown in FIG. 10A Steps 

The present invention preferably uses both RSA and DES 802C-813 create opaque label-value pair 4217 of message 

methods for data encryption and decryption. Such methods Rl, based upon the opaque section contents of message Rl, 

are well known in the art. RSA is fully described in U.S. Pat 40 shown in FIG. 10B. Steps 814-817 assemble header 4205, 

No. 4,405,829. The present invention preferably relies on transparent label-value pairs 4213A-4213D, opaque label- 

768-bit RSA keys reflecting a balance between concerns value pair 4217 and trailer 4250 of message Rl. 

relating to security, execution time, and export control. The At step 802A, customer application software 210 accesses 

size of the RSAkey may change as high-end computers with message template data structure 270 (FIG. 5A) to obtain a 

fast processing, speeds become more prevalent in customer 45 list of labels, which, when matched up with associated 

installations and the export requirements are relaxed. As is values, make up transparent label-vahie pairs 4213A-4213C 

known to those skilled in the art, other public/private asym- of message Rl. At step 802B, values are associated with 

metric key systems (such as Rabin, and ElGamal) could be each label as follows: 

used in the current invention for authentication purposes. Label-value pair 4213A has the label "transaction". The 

In the present invention, digital signatures are used to 50 value of field 4213Ais a transaction number, generated by 

authenticate information. The details of digital signatures client software 210, which uniquely identifies message Rl. 

are widely discussed in computer security literature. The The value of label-value pair 4213A allows server computer 

present invention utilizes two methods for authentication: 100, upon receipt of message Rl, (1) to send an associated 

RSA/MD5 digital signatures and knowledge of shared infor- reply message R2, described later, and (2) to determine if 

mation (e.g., a salt value and/or a key value). 55 message Rl is a duplicate message (i.e., already received by 

As mentioned above, the present invention also depends server computer 100). The value associated with label-value 

on hashing hashing of data. A has preferably is calculated pair 4213A is stored in field 251B of pending persona 

using the well-known MD5 algorithm which is described in registration/update persona information record 251 (FIG 

Internet publication RFC 1321, applied to a "synthetic 5G). - 

message 1 '. - 60 Label-value pair 4213B has the label "date". The value of 

If a label-value pair is specified in a hash input, but is not " label-value pair 4213B indicates the date and time that 

present in a message, the label and label terminator are message Rl was assembled and sent to server computer 100, 

preferably omitted from the hash. according to the clock of customer computer 200. The value 

IV. Processes of the Present Invention associated with label-value pair 4213B is stored in field 

A. Download And Installation Process 400 65 251C. 

During the download and installation process 400 as Label-value pair 4213C has the label "serverkey". As 

previously described with respect to FIG. 3A, an RSApublic* described below, a DES key/TV pair used by customer 



5,8' 

31 

computer 200 to encrypt the opaque label-value pair 4217 of 
message Rl is encrypted using an RSA public key of server 
computer 100. The value of label-value pair 4213C points to 
the corresponding RSA private key stored in server private 
key data structure 160 (JIG. 4A). 

Label-value pair 4213D has the label "service-category". 
The value of label-value pair 4213D is a label which may be 
used to route message Rl to a processor within server 
computer 100 that handles messages of a particular service 
category. This option permits the functions of server com- 
puter 100 to be distributed among multiple processors 
thereby improving capacity of the system. 

At step 802C, customer application software 210 uses 
well known techniques to generate a random 128 -bit quan- 
tity. It is preferred that the first 64-bils of the quantity so 
generated be treated as a 56-bit DES key and the second 
64-bits be treated as a 64-bit initialization vector ("TV"). The 
56-bit DES key is represented a&a 64-bit quantity having the 
least significant bit of each eight bit byte ignored. This 
128-bit quantity may be viewed as a DES key/IV pair. The 
DES key/TV* pair is stored in a temporary register. 

Next, at step 804, customer application software 210 
retrieves the RSA public key for server computer 100 from 
field 215A of client application data structure 215 (FIG. 5B). 
As stated previously, the RSA public key for server com- 
puter 100 is preferably 768-bits in length. Of course, other 
length RSA keys may be used. At step 806, the RSA public 
key retrieved at step 804 is used to encrypt the DES key/TV 
pair created at step 802. 

At step 807, customer application software 210 accesses 
message template data structure 270 (FIG. 2B) to obtain a 
list of labels, which, when matched up with associated 
values, make up the opaque section contents of message Rl, 
shown in FIG. 10B. At step 808, values are associated with 
each label as follows: 

Label-value pair 4217A has the label "type". The value of 
label-value pair 4217A references a record in message data 
structure 270 (FIG. 2B) which' sets forth the labels of 
message Rl. The value of label-value pair 4217A is obtained 
from customer application software 210 which generates the 
label when customer user 203 initiates the registration 
process. 

Label-value pair 4217B has the label "server-date". The 
value of label-value pair 4217B indicates the date and time 
message Rl was assembled as measured by customer com- 
puter 200 f s perception of the date of server computer 100* s 
clock. 

Label-value pair 4217C has the label "swversion" 
(software version). The value of label-value pair 4217C 
indicates the version of customer application software 210 
communicating with server computer 100. The value of 
label-value pair 4217C is obtained from data embedded in 
customer application software 210. The value associated 
with label-value pair 4217C is stored in field 25 ID. 

Label-value pair 4217D has the label "content-language". 
The value of label-value pair,4217D indicates a preferred 
language of communication for customer user 203. The 
value of label-value pair 4217D is obtained from customer 
user 203. during registration process 401 at step 1202. The 
value associated with label- value pair 4217D is stored in 
field 251E. 

Label-value pair 4217E has the label "default-currency". 
The value of label-value pair 4217E indicates a default 
currency in which transactions of customer user 203 will be 
processed, unless changed by customer user 203. The value 
of label-value pair 4217E is obtained from customer user 
203 during registration process 401 at step 1202 of FIG. 8. 
The value associated with label-value pair 4217E is stored in 
field 251R 
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Label-value pair 4217F has the label "requested-id , \ The 
value of label-value pair 4217F indicates the persona id 
requested by customer user 203. The value of label-value 
pair 4217E is obtained from -customer user 203 during 
5 registration process 401 at step 1202 of FIG. 8. The value 
associated - with label-value pair 4217F is stored in field 
251G. 

Label-value pair 4217G has the label "email". The value 
of label-value pair 4217G indicates an email address for 
customer user 203. The value of label-value pair 4217G is 
obtained from customer user 203 during registration process 
401 at step 1202 of FIG. 8. The value associated with 
label-value pair 4217G is stored in field 251H. 

Label-value pair 4217H has the label "agreements". The 
value of label-value pair 4217H indicates legal agreements 
15 which customer user 203 has accepted in order to use the 
present invention. Legal agreements are presented to cus- 
tomer user 203 at step 1202 of-FIG. 8. The value* -&f 
label-value pair.4217H is generated when an agreement is 
accepted by customer user 203 and stored in field 220L of 
20 customer instrument persona data structure 220 (FIG. 5Q. 
Label-value pair 42171 has the label "autoclcse- 
passphrase". The value of label-value pair 42171 indicates an 
autoclose passphrase for customer user 203. The value of 
label-value pair 42171 is provided by customer user 203 
25 during registration process 401 at step 1202 of FIG. 8. The 
value associated with label-value pair 42171 is stored in field 
220D of customer persona data structure 220 and field 2511 
of customer pending data structure 250. 
Label-value pair 4217J has the label "pubkey". The value 
30 of label-value pair 4217J represents the RSA public key for 
customer persona 120.1 generated by customer application 
software 210 during registration process 401 at step 1202A 
of FIG. 8. 

Referring again to FIG. 9, at step 810, the digital signature 
35 for message Rl, represented by label-value pair 4217K of 
FIG. 10B, is created. Label-value pair 4217K has the label 
"signature". The value of label-value pair 4217K represents 
the digital signature of customer persona 120.1. For message 
Rl, the value of label-value pair 4217K is a hash of the 
40 printable U.S. ASCII characters in the the label-value pairs 
4213A-4213C, and label-value pairs 4217A-4217J in alpha- 
betical order, encrypted with the RSA private key of cus- 
tomer persona 120.1. The RSA private key of customer 
persona 120.1 is obtained from field 220H (FIG. 5C.) 
45 At step 8 i2A, label-value pair 4217K, created in step 810, 
is appended to label-value pairs 4217A-4217J. Label-value 
pairs 4217A-4217K are encrypted with DES key/IV pair 
stored in the temporary register at step 8Q2C. At step 812B, 
the result of step 812A is appended to the RSA-encrypted 
so DES key/TV pair created in step 806. 

At step 813, data assembled at step 812B is encoded using 
well known techniques (preferably base-64), completing 
assembly of the opaque section contents of message Rl. 
Message Rl is assembled at steps 814-818. At step 814, 
55 header 4205 is created using the message template found at 
customer message template data structure 270 (FIG. 5A) and 
a protocol number embedded in customer application soft- 
ware 210. 

Next, at step 815, transparent label-value pairs 
60 4213A-4213C as described above are appended. 

At step 816, opaque label-value pair 4217 is appended. 
Label-value pair 4217 has the label "opaque" signifying that 
the value which follows is encrypted data. The value of 
label-value pair 4217, shown in FIG. 10A, represents the 
65 data which was encoded at step 813. 

Trailer 4250 is assembled at step 817. The checksum of 
trailer 4250 is calculated as described above with respect to 
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sample message 4000. Trailer 4250 is added to message Rl. At step 911, the DES key/IV pair obtained at step 909 is 

At step 818, a copy of message Rl is saved in field 25D. used to decrypt that portion of opaque label-value pair 4217 

The assembly of message Rl is now complete. Message revealing to label-value pairs 4217A-4217K of FIG. 10B. At 

assembly process 800 ends at step 819. ste p 912, the decryption of the opaque-value pair 4217 is 

Referring again to FIG. 8, registration process 401 con- 5 determined to either succeed or fail. Should the decryption 

tinues at step 1204. There, customer computer 200 transmits fail for my reaS on, processing continues at step 905 where 

message Rl to server computer 100. Customer computer wc have found it preferable t0 M an appropriate error flag 

200 waits for a reply message R2 from server computer 100 ^ ^ ^ 900 tenninates at step 917 . If 

At step 1205, server computer 100 receives message Rl ^ d ^ ^ * paque -value pair 4217 is successful, 

from customer computer 200 and unwraps message Rl by pr0C essing contmues at step 913. 
executing server message unwrap procedure 900. Server A ♦ nVa T y • a * • j w * 

message g unwrap procedure 900 is* now described with # "f"^ 15 de erm f ed * y 

reference to FIGS. 11A and UB, where it begins at step 901. t0 label-yatae pur 4217A. For example the value of label- 

At step 901 A, a copy of message Rl is stored in field val "f Pf" 42 J 7A fo 5 mes fg e R1 ma y * "registration/ 
140E (FIG. 4L). We ° ave r oun d Jt preferable to have three checks of 

At step 902, server software 110 extracts the protocol 15 message Rl performed at steps 914, 915 and 916 as follows, 
number from field 4205C of header 4205 of message Rl. Server form check of step 914 is message type and 
Next, based upon the protocol number extracted at step 902, software version dependent. That is, the. expected form of 
server message data structure 150 (FIG. 4A) is accessed to the message, and the criteria that determine whether it is 
determine the expected format of message Rl. The expected acceptable, depend on the message and any variations of the 
format may include message syntax (e.g., permitted end-of- 20 message that are valid at a given time as determined by 
line characters) and message coding (e.g., ASCII or hex). reference to message type and version data structure 150 as 
Message Rl is parsed in accordance with the expected previously described. At a minimum, the t form check pro- 
format as follows. cedure will ascertain whether an incoming message contains 

At step 903 server computer 100 calculates a checksum all the labels that are prescribed for that message, whether 

using the same data used by customer computer 200 at step 25 there are values for each label that requires a value, and 

817 of message assembly procedure 800. At step 904, the whether the values are of the type, syntax, and value range 

checksum calculated at step 903 is compared to the check- as required. If a message. can be parsed but does not meet a 

sum 4250D of trailer 4250 of message Rl. If the checksums form criteria, server computer 100 will set an error flag at 

are not equal, message Rl is discarded at step 904A where step 905 and return an error code in message R2 (described 

server message unwrap procedure 900 also tenninates. 30 later). A message which is so malformed that it cannot be 

If the checksums are equal at step 904, processing con- parsed by server computer 100 will be discarded. If the form 

tinues at step 906A where the message is checked to check at step 914 is successful, processing continues at step 

determine if it is appropriate for message unwrap procedure 915. 

900. If a message includes a label "serverkey", message At step 915, the digital signature represented by the value 

unwrap procedure 900 is appropriate. Messages received by 35 of label-value pair 4217K is verified (Pass signature test!), 

server computer 100 for which unwrap procedure 900 is First, server software 110 obtains the RSA public key for 

inappropriate will not contain the "serverkey" label but will customer persona 120.1 from the value of label- value pair 

instead include a label "type" in the transparent part of the 4217J. The RSA public key obtained from label- value pair 

message. Such messages will be unwrapped using other 4217J is used to decrypt label-value pair 4217K. Next, 

procedures' as described later. If a message is inappropriate, 40 server software 1 10 accesses message data structure 150 to 

processing continues at step 906B where the message is determine which label-value pairs were hashed at step 810 

diverted to another unwrap procedure. Message Rl is appro- of message assembly procedure 800 to compute the value of 

priatc; therefore, processing continues at step 906C where . label-value pair 4217K. Server software 110 then hashes the 

the value of opaque label-value pair 4217 is decoded. same label-value pairs which were hashed at step 810. The 

At step 907, the RSA public key used by customer 45 two hash values are compared. If the hash values differ, an 

computer 200 to encrypt the DES key/TV pair at step 806 of appropriate error flag is set at step 905. In this case, server 

message assembly procedure 800 is detennined. To do this, message unwrap procedure 900 terminates at step 917. If the 

server software 110 obtains the value of label-value pair hash values match, processing continues at step 916. 
4213C associated with the label "serverkey". The value of At step 916, a check as to whether customer application 

label-value pair 4213C is a pointer to a field in private key so software 210 is current is performed as follows. Server 

data structure 160 which stores the RSA private key com- software 110 obtains the version number of customer appli- 

ponent corresponding to the RSA public key used by cus- . cation software 210 used to assemble message Rl from the 

tomer computer 200 at step 806. value of label-value pair 4217C. The obtained value is 

At step 909, the RSA private key determined at step 907 compared to the latest supported version number of cus- 

is used to decrypt that portion of opaque label-value pair 55 tomer application software 210. - 
4217 corresponding to the RSA-encrypted DES key/IV pair. Each version has associated with it one of three "status" 

In this manner, the DES key/IV pair used to encrypt the labels. If the software check returns "current", then the 

remainder of opaque label-value pair 4217 is obtained. At customer application software 210 that constructed message 

step 909A, it is determined whether the decryption of the Rl is the latest version of that software available, No flags 

DES key/TV succeeded or failed. Should the decryption fail 60 are set and message unwrap procedure 900 ends at step 917. 

for any reason, processing continues at step 905 where we If the software check returns "warning", the version of 

have found it preferable to set an appropriate error flag and customer application software 210 is not the latest but is still 

server unwrap procedure 900 terminates at step 917. If the deemed usable, A flag is set at step 905 which will cause a 

decryption of the DES key/TV pair is successful, processing warning message to be sent to customer user 203 in message 

continues at step 910. 65 R2 (described below) and message unwrap procedure 900 

At step 910, the DES key/IV pair obtained at step 909 is ends at step 917. If the label associated with customer 

stored in a temporary register. application software 210 is "fatal", the application software 



. 5,870,473 

35 36 

is not usable and an error flag is set at step 905 which will value of label-value pair 4313A is the same as that received 

cause an error message to be seat to customer user 203 in in message Rl in label-value pair 4213A 

message R2 (described below). Message unwrap procedure Field 4313B has the label "date". The value of label-value 

900 ends at step 917. pair 4313B is the same as that received in message Rl in 

Referring again to FIG. 8, processing continues at step 5 label-value pair 4213B. 

1206. If any of the tests of steps 909 A, 912, 914, 915 or 916 Label-value pair 4313C has the label "service-category". . 

caused an error flag to be set at step 905, error processing The value of label-value pair 4313C is the same as that 

procedures are executed by server computer 100 at step received in message Rl in label-value pair 4213D. 

1215. While the level of error processing at step 1215 is At step 1002, server software U0 accesses message 

largely an adrninistrative decision, it is preferred that a 10 template data structure 150 to obtain a list of labels which, 

minimum, failures of the checksum, signature, and form, when matched up with associated values, make up the 

and a "fatal" return on the software check procedure result opaque section contents of message R2, shown in FIG. 13B. 

in a return message containing a code that can be processed Processing continues at step 1005. There, values are 

by customer application software 210 and a message that matched up with labels to form label-value pairs 

can be read by customer user 203. The error processing 15 4317A-4317K, of FIG. 13B. 

procedure in step 1215 entails associating a flag with a The opaque section contents of message R2 are shown in 

K specific error code (described later u> the context of the FIG. 13B where label-value- pair 4317A has the label "type", 

return message R2) and creating a text message (either from Label-value pair 4317A references a record in message data 

a data structure of messages or a message sent by the system structure 150 which sets forth the labels of the opaque 

administrator). Server computer 100 then generates a mes- 20 section contents of message R2. The value of label-value 

sage R2 similar to that described later to customer computer pair 4317A is obtained from server software HO. 

200 conveying the error code and any related message. ^ s Label-value pair 4317B has the label "server-date". The 

If the tests of steps 909A, 912, 914, 915 and 916 did not value of label-value pair 4317B indicates the date and time 

cause an error flag to be set at step 905, processing continues message R2 was assembled according to the clock of server 

at step 1207 where the value of label-value pair 4217F, is 25 computer 100. 

compared to the persona id of field 120A for all customer Label-value pair 4317C has the label "requested-id". The 

personas 120.1 and fieid 120AA for all merchant personas value of label-value pair 4317C indicates the persona id 

120.2 contained in server persona data structure 120. requested by customer user 203. The value of label-value 

At step 1209, if unique, server software 110 creates a new pair 4317C was received in label-value pair 4217F in 

persona 120.1 in server persona data structure 120. Infor- 30 message Rl. 

mation contained in message Rl is then transferred into the Label-value pair 4317D has the label response-id'The 

new persona 120.1 as follows: The value of label-value value of label- value pair 4317D indicates the persona id of 

4217F, and the two-digit check code, is assigned to the customer user 203, or, if the requested-id in label-value pair 

persona id of field 120A The value of label-value pair 4317C was a duplicate, indicates a suggested persona id. 

4217G, is stored in email address field 120B. The RSA 35 Label-value pair 4317E has the label "email". The value 

public key of field 120C receives the value of label-value of label-value pair 4317E indicates an email address for 

pair 4217J. The value of label-value pair 4217B is assigned customer user 203. Hie value of label-value pair 4317E was 

to field 120D. The value of label-value pair 4217D is stored received in label-value pair 4217G of message Rl. 

in field 120E. The value of label-value pair 4217H is stored Label-value pair 4317F has the label "response-code", 

in field 1201. The value of label-value pair 42171 is stored in 40 The value of label-vahxe pair 4317F indicates whether 

field 120F. In this case, processing continues at step 1217. registration process 401 was a success or failure. 

If the value of label-vahxe pair 4217F is not unique to. . Label-value pair 4317G has the label "fimoV waiting", 

server persona data structure 120 at step 1207, processing The value of label-value pair 4317G indicates if there are 

continues at step 1216. any messages holding funds waiting for the holder of the 

At step 1216, a suggested persona id is determined by 45 email address in label-value pair 4317E. Alternatively, label- 
computing a random number and appending it to the value, pair could indicate the number of such email mes- 
requested id without hyphenation. Thus, "Brian" becomes sages. Either approach provides a means by which the 
"Brianl5". In this case, processing continues at step 1217. registrant obtains any such funds preferably requires the 

At step 1217, server software 110 assembles reply mes- registrant to send server computer 100 a message containing 

sage R2, shown in FIG. 13, according to the flow diagram so a password provided by the sender of the funds, 

of FIG. 12. FIG. 12 depicts server message assembly pro- Label-value pair 4317H has the label "autoclose- 

cedure 1000. passphrase". The value label- value pair 4217H indicates an 

Server message assembly procedure 1000 begins at step autoclose passphrase for customer user 203. The value of 

1001. Steps 1001A-1001B create transparent label-value ** label-value pair 4317H was received in labeWalue pair 

pair 4313 of message R2. Steps 1002-1009 create opaque 55 42171 of message Rl. 

label-value pair 4317 of message R2. Steps 1010-1014 Label-value pair 43171 has the label "pubkey". The value 

-assemble header 4305, transparent label-value pairs of label-value pair 43171 shown in FIG. 13B represents the 

4313A-4313C, opaque label-value pair 4317 and trailer RSA public key of customer persona 120.1 received in 

4350 of message R2. label-value pair 4217J of message Rl. 

- At step 1002, server software 110 accesses message data 60 Label-value pair 43 17 J' has the label "swseverity" 

structure 150 (FIG. 4A) to obtain a list of labels, which, (software severity). The value of label-value pair 4317J 

when matched up with associated values, make up the indicates whether customer application software 210 needs 

transparent label-value pairs 4313A-4313B of message R2. to be updated, but is still usable ("warning'') or is no longer 

At step 1002B, values are associated with each label as usable ("fatal"). Tne value of label-value pair 4317J is null 

follows: 65 if customer application software 210 is current. 

Label-value pair 43 13A has the label "transaction". The Label-value pair 4317K has the label "swmessage" 

value of label-value pair 4313Ais a transaction number. The (software message). The value of label-value pair 4317K 
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indicates instructions as to what customer user 203 should 
do in the case of a "fatal" or ''warning" software severity. 
The value of label-value pair 4317K is only present if the 
value of label-value pair 4317J is not null. 

Label-value pair 4317L has the label "message". The 
value of label-value pair 4317L is a free text message 
associated with an error or success condition returned in 
label-value pair 4317F and displayed to customer user 203. 

Referring again to FIG. 12, processing continues at step 
1007. There, label-value pairs 4317A-4317L of FIG. 13B 
are assembled and encrypted with the DES key/IV pair 
decrypted at step 910. 

At step 1009, label-value pairs 4317A-h4317L encrypted 
at step 1007 are encoded using well known techniques 
(preferably base-64). 

Message R2 is assembled at steps 1010-1014. At step 
1010, header 4305 is assembled using the message and type 
data structure 150 and the protocol number from the incom- 
ing message Rl. 

Next, at step 1011, transparent label-value pairs 4313A 20 
and 4313B previously described are appended. 

At step 1012, opaque label- value pair 4317 is appended. 
Label-value pair 4317 has the label "opaque" signifying that 
the value which follows is encrypted data. The value of 
label-value pair 4317 represents the data encoded at step 
1009. 

Trailer 4350 is assembled (created) at step 1013. The 
checksum of trailer 4350 is calculated as described above 
with respect to sample message 4000. Trailer 4350 is 
appended to message R2. At step -1014, a copy of the 
complete message R2 is saved at field 140F of server 
message log data structure 140. 

The assembly of message R2 has now been completed. 
Message assembly procedure 1000 ends at step 1015. 

Referring again to FIG. 8, at step 1218, message R2 is sent 
(transmitted) from server computer 100 to customer com- 
puter 200. 

At step 1219, customer computer 200 receives message 
R2 from server computer 100 and unwraps message R2 by 
executing message unwrap procedure 1100. Message 
unwrap procedure 1100 is now described with reference to 
FIG. 14, where it begins at step 2101. 

At step 1102, customer computer software 210 extracts 
the protocol number from header 4305 of message R2. Next, 
based upon the extracted protocol number at step 1102, 
message template data structure 270 (FIG. 5A) is accessed 
to determine the expected format of message R2. The 
expected format may include message syntax (e.g., permit- 
ted end-of-line characters) and message coding (e.g., ASCII 
or hex). Message R2 is parsed in accordance with the 
expected format as follows. 

At step 1103, customer computer 200 calculates a check- 
sum using the same data used by server computer 100 at step 
1013 of server message, assembly procedure 1000. At step 
1104, the checksum calculated at step 1103 is compared to 
the checksum of trailer 4350 of message R2. If the check- 
sums are not equal, message R2 is discarded at step U04A 
where message unwrap procedure U00 terminates. 

If the checksums are , equal at 4 step 1104, processing* 
continues at step 1105A where the message is checked to . 60 
determine if it is appropriate for message unwrap procedure 
1100. If a message does not include the label "type" in the 
transparent part of the message, message unwrap procedure 
U00 is appropriate. Messages received by customer com- 
puter 200 containing the label "type" in the transparent part 
of the message will be unwrapped using other procedures 
(described elsewhere) at step U05R Here, message R2 is 
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appropriate; therefore, processing continues at step 1106 
where the value of opaque label-value pair 4317 is decoded. 

At step 1107, the DES key/IV pair stored in temporary 
register at step 802 of message assembly procedure 800 is 
retrieved. 

At step 1108, the DES key/I V pair retrieved at step 1107 
is used to decrypt the value of opaque label-value pair 4317. 
If for any reason the decryption of opaque label-value pair 
4317 is not successful, step 110? directs the processing of 
message R2 to step 1105 where an error flag is set. In this 
case processing of message unwrap procedure 1100 stops at 
step 1121. If the decryption of label-value pair 4317 is 
successful, processing continues at step 1110. 

At step 1U0, the message type is determined by reference 
to label-value pair 4317A. For example, value of label-value 
pair 4317A for message R2 may be "registration-response.'' 

A check of message R2 is^hen performed at step 1111 as 
follows. Message data structure 270 (FIG. 5A) contains data 
regarding the form of incoming messages. At a minimum , 
the form check procedure will ascertain whether an incom- 
ing message contains all the labels that are prescribed for 
that message, whether there are values for each label that 
requires a value, and whether the values are of the type (e.g.,, 
text, signed numbers, ), syntax (e.g., in the form of a valid 
e-mail address) and within any specified limits as required. 
If there are additional labels, customer computer 200 will 
ignore them. If a message cannot be parsed, or if it can be 
parsed but does not meet a form criteria, an error flag will 
be set at step 1105. 

If the message passes the form check at step Ull, 
message unwrap procedure 1100 terminates at step 1121. 

Referring again to FIG. 8, processing continues at step 
1220. There, we have found it preferable to handle error 
messages as follows: 

(1) if an error flag was set at step 1105, the flag will be 
detected at step 1220 and processing of message R2 
will terminate at step 1221. From the perspective of. 
customer user 203, no further action is taken with 
respect to message R2. In the preferred embodiment of 
the present invention, we prefer to include a mecha- 
nism within customer application software 210 to cre- 
ate and send to server computer 100 a message. This 
message includes the R2 message as received by cus- 
tomer computer 200 and any diagnosis of what caused 
the message to fail. No response to this message is sent 
by server computer 100 to customer computer 200. 
Rather, the information is used to ascertain whether a 
problem exists within the system and if appropriate 
corrective measures need to be taken. 

(2) if no error flag was set at step 1105 but an error in 
message Rl was detected at step 905 or step 1216, 
processing will continue at step 1222 where the content 
of label-value 4317F is checked. If the value of label- 
value 4317F is other than "success", error processing 
routines are performed at step 1223 causing customer 
application software 210 to display the message con- 
tained in label-value 4317K associated with the content 
of label-value 4317F and to interpret the value of 
label-value 4317F and take whatever action may be 
associated with that value. -In particular, if the only 
error flag set was detected at step 1216 indicating that 
the requested id was not unique, the id suggested by 
server computer 100 and returned in label-value pair 
4317D is displayed and the registration process is 
restarted at step 1201; or 

(3) if message Rl passed the check at step 905 and no 
flags were set at step 1105 and the id requested by 



5,870,473 

39 40 

customer user 203 was accepted by server computer Label-value pair 4413B has the label "transaction" The 

100, processing continues at step 1224 where customer value of label-value pair 4413B is a transaction number, 

application software 210 updates customer database generated by customer application software 210, which 

202 as follows: The value of label-value 4317D arid the , uniquely identifies message BU. The value associated with 

two-digit check code is assigned to the customer per- 5 label-value pair 4413B is stored in field 252B (FIG. 5H). 

sona id of field 220A. The value of label-value pair Label-value pair 4413 C has the label "date". The value of 

4317E is stored in the email address of field 220B. The label-value pair 4413B indicates the date and time that 

RSApublic key of field 220C receives the value created message BI1 was assembled and sent to server computer 

by customer application software 210 and echoed in 100, according to the clock of customer computer 200. The 

label-value pair 43171. In addition, record 261 of value associated with label-value pair 4413C is stored in 

customer log data structure 260 is created as follows: field 252C of customer pending data structure 250. 

The transaction number from label-value pair 4313 A is Label-value pair 4413D has the label "serverkey". As 

stored in field 261B. The date from label- value pair described later, the DES key/IV pair used by customer 

4317B is stored in field 261C. The requested id from computer 200 to encrypt opaque label- value pair 4417 of 

label-value pair 4317C is stored in field 261H. The message BU is encrypted using an RSApublic key of server 

response id from label-value pair 4317D is store in field 15 computer 100. The value of label-value pair 4413D points to 

2611. The email address from label-value pair 4317E is the corresponding RSA private key stored in server private 

stored in field 26D. The response-code from label- key data structure 160. 

value pair 4317F is stored in field 261F. The software . Label-value pair 4413E has the label "service-category", 

severity code from label-value pair 4317J is stored in The value of labeUvalue pair 4413 E is a label which may be 

•.field 2 6 ID. The software-message from label-value 20 used to route message BU to a processor within server 

pair 4317K is stored in field 261E. The response computer 100 that handles messages of a particular service 

message associated with the response code from field category. - ... 

4317L is stored in field 261G. Label-value pair 4417 has the label "opaque" signifying 

Processing continues at step 1225 where registration that the date which follows includes the encrypted opaque 

process 401 ends . 25 section contents of message BI1. 

C. Instrument Binding Process 403 The opaque section contents of message BU, shown in 

Instrument binding process 403 is a process by which a FIG 16B is now described 

^Tm^?^ 03 ^ trumen ^ 1 to ^ omer P erson * Label-value pair 4417A has the label "type". Tlie value of 

120.1. HG. 15 depicts a now diagram illustrating instrument , . , , . r AA «- A ■■ - J J . , ^ 

binding process 403 which begins at step 1301. ^ ^ ^ ^ f ^T^fT 

At sfe£ 1302, customer ap^^ 30 structurc 270 (FIG. 5A) which sets forth we labels of the 

(request) customer user 203 to enter information relating to °P ac } ue * ctl0u ^ ntents of messa S e BI1 - ™ e value of 

an instrument to be bound to customer persona 120.1. This label-value pair 4417A is obtained from customer applica- 

information will be included in message BU sent to server tion software 210 which generates the value when customer 

computer 100 and will become part of instrument binding USCT 203 initiates the instrument binding process 403, 
data 120H (fields 120H1-120H.28) for the instrument being 35 Label-value pair 4417B has the label "server-date", 

bound. In the preferred embodiment, customer user 203 Label-value pair 4417B indicates the date and time message 

enters the instrument number, the instrument expiration BU was assembled as measured by customer computer 

date, the instrument customer identification number, and the 200's perception of server computer 100's clock, 
name, street address, city, state, postal code, country, coun- Label-value pair 4417C has -the label "swversion" 

try code, and the telephone number (including area code) of 40 (software version). The value of label- value pair 4417C 

the instrument holder. Customer user 203 will also be asked indicates the version of customer application software 210 

to indicate whether the instrument being bound is the communicating with server computer 100. The value of 

autoclose instrument as previously described. In addition, label-value pair 4417C is obtained from data embedded' in 

customer application software 210 will create a random customer application software 210. The value associated 

number (referred to as "instrument salt'*). Customer user 203 45 with label-value pair 4417C is stored in field 252D (FIG. 

will also be asked for a description of the instrument being 5H). 

bound. This description might be in the form of "Company Label-value pair 4417D has the label "instrument- 
Credit Card" or "John's Bank Account." For bindings of number**. For security reasons, the actual instrument number 
credit cards, this information is stored in field 252R in is not stored in database 102 of server computer 100. Rather, 
customer pending transaction data structure 250. Instrument 50 the instrument number is stored in database 102 as a hash 
type, instrument category, and instrument functions are value The hash of the value associated with label-value pair 
derived by customer application software 210 from the data 4417D is stored in field 252F. 

entered by customer user 203. Label-value pair 4417E has the label "instrument- type". 

While the „data acquired at step 1302 is described with "Label- value pair 4417E indicates a type of instrument, for 

reference to a credit card instrument, it is within the knowl- 55 example, VISA, MasterCard, American Express, etc. The 

edge of one skilled in the art to modify the credit card data value of label-value pair 4417E is obtained from customer 

to accommodate debit cards, DDAs, and other financial user 203 during instrument binding process 403 at step 1302 

instruments. or may be derived by customer application software 210 

Message BI1 will be assembled by and transmitted from from .the instrument number. The value * associated with 
customer computer 200 server computer 100 to effect instru- 60 label-value pair 4417E is stored in field 252T. 
inent binding process 403. The contents of the message BU Label-value pair 4417F has the label "instrument- 
is now described with reference to FIGS. 16A and 16B. category". The value of label-value pair 4417F indicates a 

Label-value pair 4413A has the label "id". The value of category of the mstrument being bound. Categories may 

label-value pair 4413 A indicates the persona id for customer include, for example, credit cards, debit card, DDAs, etc. 

user 203. The value of label-value pair 4413A is obtained 65 The value of label-value pair 4417F is derived by customer 

from field 220A of customer persona data structure 220 application software during instrument binding process 403 

(FIG. 5B). at step 1302. 
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Label- value pair 44171 has the label "instrument- customer user 203 has accepted in order to use the present 

functions" and preferably may have any combination of the invention. The value of label-value pair 4417R is generated 

following values: "charge", "credit", "load" or "unload". from agreement accepted by customer user 203 and stored in 

The value of label-value pair 44171 indicates one or more fold 230S (FIG. 5D). 

functions that may be performed by customer user 203 with 5 Label-value pair 4417S has the label "autoclose and may 

the instrument being bound. A charge transaction occurs ^» vihie "yes" or "no"; The value of label-value pair 

when a persona 120.1 uses a bound instrument as a credit 4417S indicates whether the instrument ^b^^be 

cardtopayforaproduct.Aae^ ftrf^™^^^ 

" v J . * j** _ f „ n ~r*™* iini i;-, rt f " label-value pair 4417S is obtained from customer user 203 

where a merchant credits customer per^na mi in heu of indent binding process 403 at step 1302. 

providing the product originally agreed upon. Hie load and 10 La § el _ value k ^fifr has the i abe l "autoclose- 

unload transaction are the same as those descnbed previ- pa^tase". The value of label-value pair 4417T indicates 

ously. The function(s) of label-value pair 44171 are denved ^ passphrase (p re f C rably six to fifty characters) which, 

by customer application software 210 during instrument when used? ^ close customer persona 120.1. Label-value 

binding process 403 at step 1302. pau . 44177 ^ present only if the value of label-value pair 

Label-value pair 4417J has the label "instrument-salt". 15 4417T is "yes"; The value of label-value pair 4417T is 

The value of label-value pair 4417J indicates a crypto- provided by customer user 203 during registration process 

graphic salkused to reduce the ease by which : the value of 401. " s ' Ar * 

label-value pair 4417D (relating to the instrument number) Label-value pair 4417U has the label "key". The value of 

can be determined. The value of label-value pair 4417J is label-value pair 4417U represents a hash of the modulus part 

generated by customer application software 210 during 20 of the RSA public/private key pair for customer persona 

instrument binding process 403 at step 1302V The value 120.1. The value of label-value pair 4417U permits server 

associated with label-value pair 4417J is stored in field 252U computer 100 to confirm that the RSApublic key maintained 

(FIG. 5H). in field 120B (FIG. 4B) is the same key used to sign message 

Label-value pair 4417K has the label "instrument- BI1 (label-value pair 4417V). 

expiration^date". The value of label-value pair 4417H indi- 25 The digital signature of message BI1, represented by 

cates the expiration date of the instrument being bound. The labei-value pair 4417V, has the label "signature". The value 

value of label-value pair 44i7K is obtained from customer of label-value pair 4417V represents the digital signature of 

user 203 during instrument binding process 403 at step 1302. customer persona 120.1. For message BI1, the value of 

The value associated with label-value pair 4417K is stored label-value pair 4417V is preferably a hash of label-value 

in field 2521. 30 pairs 4413A-4413D, and label-value pairs 4417A-4417U in 

Label-value pair 4417Lhas the label "instrument-name". alphabetical order, encrypted with the RSA private key of 

The value of label-value pair 4417L indicates the name of customer persona 120.1. the RSA private key of customer 

the holder of the instrument being bound. Hie value of persona 120.1 is obtained from field 220H (FIG. 5Q. 

label-value pair 4417L is obtained from customer user 203 Referring again to FIG. 15, at step 1303, message BU is 

during instrument binding process 403 at step 1302. The 35 assembled in accordance with message assembly procedure 

value associated with label-value pair 4417L is stored in 800, depicted in FIG. 9. Message assembly procedure 800 

field 252H. was described previously for the assembly of registration 

Label-value pair 4417M has the label "instrument- . message Rl, with the following modification noted for 

address". The value of label-value pair 4417K indicates the message BI1: A copy of message BI1 is preferably saved in 

street address of the holder of the instrument being bound. 40 field 252W (FIG. 5H) instrument binding process 403 con- 

The value of label-value pair 4417M is obtained from tinues at step 1304. There, customer computer 200 transmits 

customer user 203 during instrument binding process 403 at message BI1 to server computer 100. Customer computer 

step 1302. 200 waits for reply message BI4 from server computer 100. 

Label-value pair 4417N has the label "instrument-city". At step 1305, server computer 100 receives message BI1 

The value of label- value pair 4417N indicates the city of the 45 from customer computer 200 and unwraps message BI1 by 

holder of the instrument being bound. The value of label- executing server message unwrap procedure 900 (steps 

value pair 4417N is obtained from customer user 203 during 901-917). Server message unwrap procedure 900 (steps 

instrument binding process 403 at step 1302. 901-917) was previously described with reference to FIG. 

Label-value pair 44170 has the label "instrument-state". 11 for message Rl. 

Thevalue of label-value pair 44170 indicates the state of the 50 At step 1306, if any of the tests of steps 909A* 912, 914, 

holder of the instrument being bound. The value of label- 915 or 916 caused an error flag to be set at step 905, error 

value pair 44170 is obtained from customer user 203 during . processing procedures are executed by server computer 100 

instrument binding process 403 at step 1302. at step 1313. 

Label-value pair 4417P has the label "instrument-postal- While the level of error processing at step 1313 is largely 

code". Label-value pair 4417P indicates the postal code of 55 an adinimstrative decision, it is preferred that a min imu m , 

the holder of the instrument being bound. The value of failures of the checksum, signature, and form, and a "fatal" 

label-value pair 4417P is obtained from customer user 203 return on the software check procedure result in a return 

during instrument binding process 403 at step 1302. message containing a code that can be processed by cus- 

Label-value pair 4417Q has the label "instrument- tomer application software 210 and a message that can be 
country". The value of label-value pair 4417Q indicates the* 60 read by customer user 203. The error processing' procedure 

country, of the holder of the instrument being bound. The in step 1313 entails associating a flag with a specific error 

value of label-value pair 4417Q is obtained from customer code (described in the context of the return message BI4 

user203 during instrument binding process 403 at step 1302. below) and creating a text message (either from a data 

The value associated with label-value pairs structure of. messages or a message sent by the system 

4417K-4417Q are stored in fields 252H-252N (FIG. 5H). 65 administrator). Server computer 100 then sends a message 

Label-value pair 4417R has the label "agreements". BI4 similar to that described later to customer computer 200 

Label-value pair 4417R indicates which legal agreements conveying the error code and any related message. - 
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If the tests of steps 909A, 912, 914, 915 and 916 did not 
cause an error flag to be set at step 905, processing continues 
at step 1307. There, information contained in message BI1 
is transferred into the instrument binding data 120H (fields 
120H.1-120H.28) (FIG. 4D) as follows: The value of label- 
value pair 4413A is stored in the persona id of field 120H.1. 
The value of label-value pair 4417 A is stored in the instru- 
ment type of field 120H.2. The value of label-value pair 
4417B is stored in the instrument bind date of field 120H.13. 
If the instrument being bound is selected by customer user 
203 as the autoclose instrument, the value of label-value pair 
4417D is stored in the instrument number of field 120H.4. It 
is preferred that this value be encrypted using an RSA key 
known only to the system operator. If the instrument being 
bound is not the autoclose instrument of the persona, the 
value of label-value pair 4417D is not stored at server data 
structure 102 but is hashed along witrTthe value in label-, 
value pair 4417J and stored in the instrument hash of field 
120H.9 The value of label-value pair 4417E is stored in the 
instrument sub type of field 120H.3. The value of label-value 
pair 4417F is stored in the instrument type of field 120H.2. 
The value of label-value pair 4417R is stored in- the legal 
agreements of field 120H.7. The value of label-value pair 
4417S is stored in the autoclose binding of field 120F. 

After step 1307, message BI4 will be assembled by and 
transmitted from server computer 100 to customer computer 
200 to complete instrument binding process 403. The con- 
tents of the message BI4 is now described with reference to 
FIGS. 17A and 17B. 

Label-value pair 44.113Ahas the label "id". The value of 
label-value pair 44.U3A indicates the persona id for cus- 
tomer user 203. The value of label-value pair 44.113 A is the 
same as that received in message BU in label-value pair 
4413A 

Label-value pair 44.113B has the label "transaction". The 
value of label-value pair 44.113B is a transaction number. 
The value of label-value pair 44.113B is the same as that 
received in message BI1 in label-value pair 4413B. 

Field 44.113C has the label "date". The value of label- 
value pair 44.113C is the same as that received in message 
BI1 in label-value pair 4413C. 

Label-value pair 44. 113 D has the label "service- 
category". The value of label- value pair 44.113D is the same 
as that received in message BU in label-value pair 4413E. 

The opaque section contents of message BI4, shown in 
FIG. 17B, is now described. 

Label-value pair 44.117A has the label "type". Tne value 
of label-value pair 44. 117 A references a record in message 
data structure 270 (FIG. 5A) which sets forth labels of the 
opaque section contents of message BI4. The value of 
label-value pair 44.H7A is obtained from server software 
110. 

Label-value pair 44.117B has the label "server-date". The 
value of label-value pair 44.117B indicates the date and time 
message BI4 was assembled according to the clock of server 
computer 100. 

Label-value pair 44.li7C.has the label "response-code" 
and preferably the value "success" or "failure". The value of 
label-value pair 44. 117C indicates whether instrument bind- 
ing process 403 was a success or failure. 

Label-value pair 44.117D has the label "swseverity" 
(software severity) and preferably the value "fatal" or 
"warning". The value of label-value pair 44.117D indicates 
whether customer application software 210 needs to be 
updated, but is still usable ("warning") or is no longer usable 
("fatal"). The value of label-value pair 44.117D is null if 
customer application software 210 is current. 
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Label-value pair 44.117E has the label "swmessage" 
(software message). The value of label-value pair 44.117E 
provides instructions as to what customer user 203 should do 
in the case of a "fatal" or "warning" software severity. The 
5 value of label-value pair 44.117E is only present if the value 
of label-value pair 44.117D is not null. 

Label-value pair 44.117F has the label "instrument- 
number". The value of label-value pair 44.117F indicates the 
number of the instrument being bound as described above. 
10 The value of label-value pair 44.117F is obtained from 
label-value pair 4417D of message BU. 

Label-value pair 44.117G has the label "instrument-type". 
The value of label-value pair 44.117G indicates a type of 
instrument. The value of label-value pair 44.117G is 
is obtained from label-value pair 4417E of message BI1. 

Label-value pair 44.117H has the label "instrument-salt". 
The value of label-value pair 44.117H from label-value pair 
4417 J of message BI1. 

Label-value pair 44.117J has the label "instrument- 
20 functions" and may have any combination of the following 
values: "sale", "credit", "load" or "unload" as previously 
described Label-value pair 44.117J indicates one or more 
functions that may be performed by customer user 203 with 
the instrument being bound. The value of label-value pair 
25 44.117J is obtained from label-value pair 44171 of message 
BI1. 

Label-value pair 44.U7K has the label "instrument*" and 
represents any number of label-value pairs whose labels start 
with "instrument" that are provided to customer user 203 in 
30 message BI4 (as previously described) and returned to 
server computer 100 in message LU1 when the instrument 
is used to load or unload funds. In this way, server computer 
100 may receive information regarding the instrument when 
necessary without storing that information in its data struc- 
35 tures. Trie particular data-value pairs that are contained in 
label-value pair 44.117K depend on the type of the bound 
instrument and the requirements of the issuer of the instru- 
ment. For example, a credit card might require the card 
number, the card expiration date, and the name and address 
40 of the card holder to be returned to the server each time the 
card is used to load funds into person 120.1. 

Label-value pair 44.1T7L has the label "message". The 
value of label-value pair 44.117L is a free text message 
associated with an error or success condition returned in 
45 label-value pair 44.117C and displayed to customer user 
203. Hie value of label-value pair 44.117L may include a 
message indicating a bad digital signature or an ill formed 
registration message Bill and instructions as to how cus- 
tomer user 203 should proceed (e.g., "call system 
50 adrninistrator"). 

Referring again to FIG. 15, at step 1308A, message BI4 
is assembled in accordance with server message assembly 
procedure 1000, depicted in FIG. 12. Server message assem- 
bly procedure 1000 was described previously for the assem- 
55 bly of registration message R2. At step 1308B, message BI4 
is sent to sever computer 100. 

At step 1309, customer computer 200 receives message 
BI4 from server computer 100 and unwraps message BI4 by 
executing message unwrap procedure 1100 (step 
60 1101-1121). Message unwrap procedure 1100 was previ- 
ously described with reference" to FIG. 14 for message R2. 
At step 1310, 

(1) if an error flag was set at step 1105, the flag will be 
detected at step 1310 and processing of message BI4 
65 will terminate at step 1311. From the perspective of 
customer user 203, no further action is taken with 
respect to message BI4. In the present invention, a 
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mechanism is provided within customer application 
software 210 to create and send to server computer 100 
a message. This message includes the BI4 message as 
received by customer computer 200 and any diagnosis 
of whatcaused the message to fail. No response to this 
message is sent by server computer 100 to customer 
computer 200. Rather, the information is used to ascer- 
tain whether a problem exists within the system and if 
appropriate corrective measures need to be taken. 

(2) if no error flag was set at step 1105 but an error in 
message BI1 was detected at step 905, processing will 
continue at step 1312 where the content of label-value 
44.117C is checked. If the value of label-value 44.117C 
is other than "success", error processing routines are 
performed at step 1314 causing customer application 
software 210 to display the message contained in 
label-value 44.117L associated with the content of 
label-value 44.117C and the interpret the .value of 
label-value 44.117C and take whatever action may be 
associated with that value; or 

(3) if message BI1 passed the check at step 905 and no 
error flags were set at step 1105, processing continues 
at step 1315 where customer application- software 210 
updates customer database 202 as follows: The instru- 
ment number from label-value pair 44.117F is stored in 
field 230A (FIG. 5D). The content of label-value pair 
44.U7J is used to set flags in fields 230L-230O. The 
result code contained in label-value pair 44.117C is 
saved in field 230P. The content of label-value pair 
44.LL7K is stored in field 230R. In addition, a new 
record 262 (FIG. 50) of customer log data structure 
260 is created as follows: The transaction number from 
label-value pair 44.113B is stored in field 262B. Hie 
date from label-value pair 44.11 7B is stored in field 
262C. The response-code from label- value pair 
44.U7C is stored in field 262F. The software severity 
code from label-value pair 44.117D is stored in field 
262D. The software-message from label-value pair 
44.117E is stored in field 262E. The instrument-number 
from label-value pair 44.117F is stored in field 2621. 



10 



15 



20 



25 



30 



35 



load/unload funds process 405. The contents of the message 
LU1 is now described with reference to FIGS. 19 A and 19B. 

Label-value pair 4513A has the label "id". Label-value 
pair 4513 A indicates the persona id for customer user 203. 
The value of label-value pair 4513A is obtained from field 
220A (FIG. 5C). The value associated with label-value pair 
4513A is stored in field 255E (FIG. 5K). 

Label-value pair 4513B has the label "transaction". The 
value of label-value pair 4513B is a transaction number, 
generated by customer application software 210, which 
uniquely identifies message LU1. The value of label-value 
pair 4513B allows server computer 100, upon receipt of 
message LU1, (1) to send an associated reply message LU2, 
described later, and (2) to determine if message LU1 is a 
duplicate message (i.e., already received by server computer 
100). The value associated with label-value pair 4513B is 
stored in field 255B. 

Label-value pair 4513C has the label^date": The value of 
label-value pair 4513C indicates the date and time that 
message LU1 was assembled and sent to server computer 
100, according to the clock of customer computer 200. The 
value associated with label-value pair 4513C is stored in 
field 255E. 

Label-value pair 4513D has the label "serverkey". As 
described below, the DES key/IV pair used by customer 
computer 200 to encrypt the opaque label-value pair 4517 of 
message LU1 is encrypted using an RSA public key of 
server computer 100. The value of label-value pair 4513D 
points to the corresponding RSA private key stored in server 
private key data structure 160. 

Label-value pair 4513E has the label "service-category". 
The value of label-value pair 4513 E is a label which may be 
used to route message LU1 to a processor within server 
computer 100 that handles messages of a particular service 
category. 

Label-value pair 4517 has the label "opaque" signifying 
that the data which follows includes the encrypted opaque 
section contents of message LU1. The opaque section con- 
tents of message LU1, shown in FIG. 19B, is now described. 

Label-value pair 4517Ahas the label "type". The value of 
label-value pair 4517A references a record in message data 



The instrument-type from label-value pair 44.H7G is 40 structure 150 (FIG. 4A) which sets forth the labels of the 



stored in field 262J. The response message associated 
with the response code from field 44.U7L is stored in 
field 262G. 

Processing continues at step 1316 where instrument bind- 
ing process 403 ends. 
D. Load/Unload Funds Process 405 

FIG. 18 depicts a flow diagram illustrating load/unload 
process 405 which begins at step 1401. 

At step 1401A, customer user 203 selects whether cus- 
tomer user 203 desires to load or unload (operation) funds. 
For the purposes of this description, it is assumed that 
customer user 203 selects to load funds. Unloading funds 
follows the same process with the exception that funds to be 
unloaded are specified as a negative quantity. 

At step 1402, customer application software 210 accesses 
field 230O of record 230.1 for all instruments bound to 
persona 120,1 and displays a list of all instruments enabled 
for load operations. At step 1403, customer user 203 is 
prompted select an instrument from the displayed list from 
which to load funds into cash container represented by cash 
container data field 120G and 2201. 

At step 1406, customer user 203 is prompted (requested) 
to enter an amount of funds in a specified currency to load 
from the mstrument selected at step 1402 into cash container 
120G, 

Message LU1 will be assembled by and transmitted from 
customer computer 200 to server computer 100 to effect 
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opaque section contents of message. LU1. The value of 
label-value pair 4517A is obtained from customer applica- 
tion software 210 which generates the label when customer 
user 203 initiates the load/unload process 405. 

Label-value pair 4517B has the label "server-date". The 
value of label- value pair 4517B indicates the date and time 
message LU1 was assembled as measured by customer 
computer 200's perception of server computer 100*s clock. 

Label-value pair 4517C has the label "swversion" 
(software version). The value of label- value pair 4517C 
indicates the version of customer application software 210 
communicating with server computer 100. The value of 
label-value pair 4517C is obtained from data embedded in 
customer application software 210. The value associated 
with label-value pair 4517C is stored in field 255D (FIG. 
5K). 

Label-value pair 4517D has the label "amount". The value 
of label-value pair 4517D represents the currency type and 
the amount of funds to be transferred from the bound - 
instrument selected at step 1402 to the cash container 120G 
for customer user 203. For unload operations, the amount of 
funds is a negative quantity. Thus, for unloads, the value of 
label-value pair 4517D represents the currency type and the 
amount of funds to.be transferred from cash container 120G 
to the bound instrument selected at step 1402. The value 
associated with label-value pair 4517D is stored in field 
255G. 
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Label-value pair 4517E has the label "instrument" and Label-value pair 45.113Ahas the label "id". The value of 

represents all of the label-value pairs returned by server label-value pair 45.113A indicates the persona id for cus- 

computer 100 in message BI4 in label-value pair 44.U7K tomer user 203. The value of label-value pair 45,H3Ais the 

(FIG. 17A) whose labels start with "instrument". The value same as that received in message LU1 in label-value pair 

of label-value pair 4517E is unique to the instrument from s 4513A 

which the bad operation is to be performed and identifies Label-value pair 45.113B has the label "transaction". The 

that instrument to server computer 100. value of label-value pair 45.H3B is a transaction number. 

Label-value pair 4517F has the label "key". The value of ^ value of label-value pair 45.113B is the same as that 

label-value pair 4517K represents a hash of the modulus part in message > LU1 m lar^l-value pair 4513B. 

oftheRSApubhc/privatekeypairusedbycustomerpersona 10 *™ ^ has me iab^l "date TTie value 

120.1 Hie value of label-value pair 4517F permits server of labe1 ^ P^ ^ 11 ^ 0 * ^ "™" as reCeiVed m 

computer 100 to confirm that the RSApublic key maintained « ,i m • *U i u i « 

- £ iji^/ctp at>\ * *u i j* ■ Label-value pair 45.113D has the label "service- 

m field 120B (FIG. 4B) isthe same key used to sign message categorr , ^ v £ ue of i abc l. va lue pair 45.113D is the same 

LU1 (label-value pan : 4517F). as that received in message LU1 in label-value pair 4513E. 

Referring agam to FIG. 18, at step 1407, message LU1 is 15 ^ cheats of mc rcply message LU2, 

assembled in accordance with message assembly procedure SDOwn ^ pj Gi 2 0B, is as follows: 

800, (FIG. 9). Message assembly procedure 800 was Label-value pair 45.117A has the label "type". Label- 
described previously for the assembly of registration mes- value of label-value pair 45.U7A references a record in 
sage Rl, with the following modification noted for message message data structure 270 (FIG. 5A) which sets forth the 
LU1. A copy of message LU1 is preferably saved in field 20 labels of the opaque section contents of message LU2. The 
140E (FIG. 4L). value of label-value pair 45.11 7A is obtained from server 

LoaqVunload process 405 continues at step 1408. There, software 110. , ; 

customer computer 200 transmits message LU1 to server Label-value pair 45.117B has the label "server-date"; 

computer 100. Customer computer 200 waits for a reply Label-value pair 45.117B indicates the date and time mes- 

message LU2 from server computer 100. 25 - sa S e LU2 was assembled according to the clock of server 

At step 1409, server computer 100 receives message LU1 computer 100. 

from customer computer 200 and unwraps message LU1 by Label-value pair 45.117C has the label "amount". The 

executing server message unwrap procedure 900 (steps value of label-value pair 45.117C is the amount transferred 

901-917). Server message unwrap procedure 900 was pre- * e b T ^enlrfed by label-value pair 

viously described with reference to FIG. 11 for message Rl. 30 

- / • „ 0fT01 -„ tn ctpq « a „ nA 11TJ ^„^ cc : n „ Label-value pair 45.117D has the label "response-code" 

Referring again i to FIGS. 1^ and 11B processuig con- ^ ^ yalue Ql ufailufe „ described . 

Unues at step .1410, if any of the tests of steps 909A, 912, ubel-vahie pair 45.117D indicates whether load/unload 

914, 915 or 916 caused an error flag to be set at step 905, piocess m was a sacccss QT failure 

error processing procedures are executed by server computer Ubel-value pair 45.117E has the label "message". The 
100 at step 1417. While the level of error processing at step 35 value of label-value pair 45.117E is a free text message 

1417 is largely an administrative decision, it is preferred that explaining the "response-code" value of label-value pair 

a minimum, failures of the checksum, signature, and form, 45.1T7D. 

and a "fatal" return on the software check procedure result Label-value pair 45.117F has the label "swseverity" 

in a return message containing a code that can be processed (software severity) and the value "fatal" or "warning". The 
by- customer application software 210 and a message that 40 value of label-value pair 45.117F indicates whether cus- 

can be read by customer user 203. The error processing tomer application software 210 needs to be updated, but is 

procedure in step 1417 entails associating a flag with a still usable ("warning'') or is no longer usable ("fatal"). The 

specific error code (described in the context of the return value of label-value pair 45.117F is null if customer appli- 

message LU2 below) and creating a text message (either cation software 210 is current 

from a data structure of messages or a message sent by the 45 Label-value pair 45.117G has the label "swmessage" 

system administrator). Server computer 100 then generates (software message). The value of label-value pair 45.117G 

a message LU2 similar to that described below to customer indicates instructions as to -what customer user 203 should 

computer 200 conveying the error code and any related do in the case of a "fatal" or "warning" software severity, 

message. The value of label- value pair 45.117G is only present if the 

If the tests of steps 909A, 912, 914, 915 and 916 did not so value of label-value pair 45.117D is not null, 

cause an error flag to be set at step 905, processing continues Label-value pair 45 .U7H has the label "fee". The value of 

at step 1411. There, information contained in message LU1, label-value pair 45.U7H indicates a fee charged to customer 

that is, the amount represented by label-value pair 4517D, is user 203, if any, associated with server computer 100 

updated to the amount in the^cash container of field 120G.2 processing message LU1. Tfie fee, if any, will be deducted 

of persona 120.1 for customer user 203 in server persona 55 from cash container field 120 G. 2. 

data structure 120. At this point, server computer 100 will Label-value pair 45.1171 has the label balance". The 
cause funds from the instrument referenced in the message value of label-value pair 45.1171 indicates the available 
LU1 to be transferred the agency account identified in cash balance in cash container field 120G2 for customer user 
container field 120G.4. Funds requested in message LU1 203. This balance reflects the previous balance, of the cash 
may be placed "on-hold" in such a way that they are not 60 container adjusted by the amount value of label-value pah- 
available until some additional conditions have been met, 45.117C loaded via message LU1 and the fee value of 
such as twenty-four hours having elapsed. label-value pair 45.117H. 

After step 1411, message LU2 will be assembled by and Label-value pair 45.117J has the label "session-funds", 

transmitted from server computer 100 to customer computer The value of -label-value pair 45.117J indicates the amount 

200 to complete loadAmload funds process 405. The con- 65 transferred from cash container field 120G.2 to the opening 

tents of the message LU2 is now described with reference to amount field 130E of server session data structure 130 for all 

FIGS. 20A and 20B. open sessions. 
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Label-value pair 45.117K has the label "on-hold\ The Processing continues at step 1420 where load/unload 

value of label- value pair 45.U7K is obtained from cash process 405 ends, 

container field 120G.3 and indicates the amount of funds E. Open Session Process 407 

pending transfer from the bound instrument identified by FIG. 21 depicts a flow diagram illustrating open session 

label-value pair 4517E of message LU1 to cash container 5 process 407 which begins at step 1501.- 

field 120G.2 for customer user 203. This value represents At step 1502, customer application software 210 prompts 

funds which are awaiting approval or processing by the (requests) customer user 203 to enter information relating to 

issuer of the instrument from which funds are being loaded the session to be created. This information will be included 

or to which funds are being unloaded. in message OS1 sent to server computer 100 and will 

At step 1412 of FIG. 18, server software 110 assembles become part of session data structure 130 (FIG. 4H). In the 

reply message LU2 according to the flow diagram of FIG. preferred embodiment, customer user 203 enters the rnaxi- 

12. Server message assembly procedure 1000 was described mum length of time the session will last, -the maximum 

previously for the assembly of registration message R2. number of transactions which may occur during the session 

Referring again to FIG. 14 message LU2 is sent from and the amount and currency of electronic cash available to 

server computer 100 to customer computer 200 at step customer user 203 during the session. Customer user 203 

1412A 15 ma y ajgQ cn ter an optional description of the session. 

At step 1413, customer computer 200 receives message Message OS1 will be assembled by and transmitted from 

^ LU2 from server computer 100 ^and unwraps message LU2 customer computer 200- to server computer 100 to effect, 

by executing message unwrap procedure 1100 (steps open session process 407. The content of message OS1 is 

1101-1121). Message unwrap procedure 1100 was described now described with reference to FIGS. 22A and 22B. 

previously with reference to FIG. 14 for message R2. 20 Label-value pair 4613A has the label "id"; The value of 

At step 1414, - label-value pair 4613 A indicates the persona id' for customer 

(1) if an error flag was set at step 1105, the flag will be user 203. The value of label-value pair 4613A is- obtained 
detected at step 1414 and processing of message LU2 from field 220A (FIG. 5Q. 

will terminate at step 1415. From the perspective of Label-value pair 4613B has the label "transaction". The 

customer user 203, no further action is taken with 25 value of label-value pair 4613B is a transaction number 

respect to message LU2. In the present invention, a generated by customer application software 210, which 

mechanism ^is provided within customer application uniquely identifies message OS1. The value of label-value 

software 210 to create and send to server computer 100 pair 4613B aUows server computer 100, upon receipt of 

a message. This message mcludes the LU2 message as message OS1, (1) to send an associated reply message OS2, 

received by customer computer 200 and any diagnosis 30 described below, and (2) to determine if message OS1 is a 

of what caused the message to fail. No response to this duplicate message (i.e., already received by server computer 

message is sent by server computer 100 to customer ioq). The value associated with label-value pair 4613B is 

computer 200. Rather, the information is used to ascer- sto red in field 256B (FIG. 5L) 

tain whether a problem exists within the system and if Label-value pair 4613C has the label "date". The value of 

appropriate corrective measures need to be taken. 3S label-value pair 4613B indicates the date and time that 

(2) if no error flag was set at step 1105 but an error in message OS1 was assembled and sent to server computer 
message LU1 was detected at step 905, processing will ioq, according to the clock of customer computer 200. The 
continue at step 1416 where the content of label-value value associated with label-value pair 4613C is stored in 
45.117D is checked. If the value of label-value 45 .117D field 256C. 

is other than "success", error processing routines are 40 Label-value pair 4613D has the label "serverkey"; As 

performed at step 1418 causing customer application described below, the DES key/I V pair used by customer 

software 210 to display the message contained in computer 200 to encrypt the opaque label-value pair 4617 of 

label-value 45.117E associated with the content of message OS1 is encrypted using an RSApublic key of server 

label-value 45.117D and to interpret the value of label- computer 100. Label-value pair 4613D points the corre- 

value 45.117D and take whatever action may be asso- 45 sponding RSA private key stored in server private key data 

ciated with that value; or structure 160. 

(3) if message LU1 passed the check at step 905 and no Label-value pair 4613E has the label "service-category", 
flags were set at step 1105, processing continues at step The value of label-value pair 4613E is a label which may be 
1419 where customer application software 210 updates used to route message OS1 to a processor within server 
customer database 202 by storing the content of cash so computer 100 that handles messages of a particular service 
container field 220J of customer persona data structure category. 

220. Label-value pair 4617 has the label "opaque". The value 
In addition, a new record 264 of customer log data of label-value pair 4617 includes the opaque section con- 
structure 260 is cre&ed as follows: The persona id from tents (in encrypted form) of message OS1. We now describe 
label-value pair 45.113A is stored in field 264H. The trans- 55 the opaque section contents of message OS1, shown in FIG. 
action number from label -value pair 45.113B is stored in 22B. 

field 264B. The date from label-value pair 45.U7B is stored Label-value pair 4617Ahas the label "type". The value of 

in field 264C. Trie amount from label-value pair 45.117C is . label-value pair 4617A references a record in message data 

stored in field 264J. The response-code from label-value pair . . structure 150 which sets forth the labels of the opaque 

45.U7D is stored in field 264F. The response message 60 section contents message OSl.The value of label-value pair 

associated with the response code from field 45.U7E is 4617A is obtained from customer application software 210 

stored in field 264G. The software severity code from which generates the label when customer user 203 initiates 

label-value pair 45.117F is stored in field 264D. The the open session process 407. 

software-message from label-value pair 45.117G is stored in Label-value pair 4617B has the label "server-date". The 

field 264E. The fee from label-value pair 45.117H is stored 65 value of label-value pair 4617B indicates the date and time 

in field 264K The balance from label-value pair 45.1171 is • message OS1 was assembled as measured by customer 

stored in field 264L. computer 200's perception of server computer 100's clock. 
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Label-value pair 4617C has the label "swversion" message unwrap procedure 900 (steps 901-917) was 
(software version). The value of label-value pair 4617C described previously for message Rl with reference to FIG. 
indicates the version of customer application software 210 11. The following modification is noted: Acopy of message 
communicating with server computer 100. The value of OS1 is stored in field 140E (FIG. 4L). 
label-value pair 4617C is obtained from data embedded in 5 At step 1506, if any of the tests of steps 909A, 912, 914, 
customer application software 210. The value associated 915 or 916 caused an error flag to be set at step 905, error 
with label-value pair 4617C is stored in field 25 6D. processing procedures are executed by server computer 100 

Label-value pair 4617D has the label "record-note". The at step 1514. While the level of error processing at step 1514 
value of label-value pair 4617D is an optional short text note . is largely an administrative decision, it is preferred that a 
to be stored in field 130M (FIG. 4H). For example, the note 10 minimum, failures of "the checksum, signature, and form, 
may state "Christmas Shopping" or "ski equipment". The and a. "fatal" return on the software check procedure result 
value of label-value pair 4617D is obtained from customer in a return message containing a code that can be processed 
user 203 J s response to a prompt from customer application by customer application software 210 and a message that 
software 210 and is preferably limited to sixty characters to can be read by customer user 203. The error processing 
simplify me display produced by customer application soft- is procedure in step 1514 entails associating a flag with a 
ware 210. specific error code (described in the context of the return 

Label-value pair 4617E has the label "amount" and toe,* _ message OS2 below) and creating a text message (either 
value entered at step 1502 indicating the maximum amount "from a data structure of messages or a message sent by the 
of electronic cash available to customer user 203 during the system administrator). Server computer 10D then generates 
session. The value associated with label-value pair 4617E is 20 a message OS2 similar to that described below to customer 
stored in field 256E " computer 200 conveying the error code and any related 

Label-value pair 4617F has the label "key-lifetime" and . message. u.. 
the value entered at step 502 indicating the maximum length If the tests of steps 909A, 912, 914, 915 and 916 did not 
of time the session will last as requested by customer user cause an error flag to be set at step 905, processing continues 
203. The value associated with label-value pair 4617F is 25 at step 1507. There, server computer 100 calculates 
stored in field 256H. (computes) a session identification number ("session id"), a 

Label-value pair 4617G has the label "key-use-lirnit" and session encryption/decryption key ("session key") and a 
the value entered at step 1502 indicating the maximum session salt and validates the session limits requested by 
number of transactions which may occur during the session customer user 203 as reflected in message OS1. 
as requested by customer user 203. Hie value associated 30 The session id is a 64-bit quantity that uniquely identifies 
with label-value pair 4617G is stored in field 256G. the session being created. Uniqueness is ensured because the 

Label-value pair 4617H has the label "key". The value of session ids are sequentially generated by server computer 
label-value pair 4617H represents a hash of the modulus of 100. 

the RSApublicyjprivate key pair of customer persona 120.1. The session-key is a 128-bit quantity containing a 56 bit 
The value of label-value pair 4617H permits server com- 35' DES key (64-bits with the least significant bit of each eight 
puter 100 to confirm that the RS A public key maintained in bit byte ignored) and a 64-bit initialization vector, 
field 120B (FIG. 4B) is the same key used to sign message The session-salt is an 8-byte cryptographic salt used to 
OS1 (label-value pair 46171). strengthen the authentication of messages CA1-CA4 which 

Label-value pair 46171 has the label "signature", The ' are exchanged during a session. Messages CA1-CA4 are 
value of label-value pair 46171 represents the digital signa- 40 described later. 

hire for customer persona 120.1. For message OS1, the value The session limits requested by customer user 203 are the 
of label-value pair 46171 is a hash of label-value pairs amount value of label-value pair 4617E, the key-lifetime 
4613A-4613D and label-value pairs 4617A-4617H in value of label-value pair 4617F, and the key-uselimit value 
alphabetical order, encrypted with the RS A private key for of label-value pair4617G. With respect to the key-lifetime 
customer persona 120.1. The RSA private key for customer 45 and key-uselimit, it is preferred that these values be subject 
persona 120.1 is obtained from field 220H (FIG. 5C). to a fixed range established by server computer 100 to 

Message OS1 is assembled using message assembly pro- improve system efficiency and maximize the security of 
cedure 800 (FIG. 9) described previously for the assembly transactions performed during a session. Server computer 
of registration message Rl. The following modification is 100 verifies that the requested values are within any such 
noted for message OS1: A copy of message OS1 is prefer- so limits. Any requested limit that exceeds a permitted value 
ably saved in field 2561. are ignored and the maximum permitted value imposed by 

In the case of assembly of message OS1 by merchant server computer 100. 
computer 300, a new record 370.1 (FIG. 7C) is created as The value of Label-value pair 4617E represents the 
follows: :: amount of electronic funds that customer user 203 desires to 

The value of label-value pair 4613B is stored in field 55 spend during the session. The actual amount of such funds 
370P. The value of label-value pair 4617F is stored in field made available to customer user 203 during a session may 
370Q. The value of label-value pair 4617G is stored in field be less than or equal to the amount requested by customer 
370R. The value of status field 370O is set to "attempt" by user 203 at step 1502. For example, customer user may 
merchant application software 310. request more electronic cash than is available, in cash 

Referring again to FIG. 15, open session process 407 60 container-field 120G.2 for customer- user 203. In this case, 
continues at step 1504. There, customer computer 200 the amount granted, as indicated by label-value pair 47171 
transmits message OS1 to server computer .100. Customer described below, is limited to the amount stored in cash 
computer 200 waits for a reply message OS2 from server container field 120G.2 for customer user 203. 
computer 100. At step 1508, server session data structure 130 (FIG. 4H) 

At step 1505, server computer 100 receives message OS1 65 is updated. The session id is stored in the session id field 
from customer computer 200 and unwraps message OS1 by 130A The session key is stored in the session key field 
executing server message unwrap procedure 900. Server 130B. The session salt is stored in the session salt field 
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130C. The amount of electronic cash made available to 
customer user 203 during the session is stored in opening 
amount field 130E and the currency designator associated 
with the value stored in field 130E is stored in field 130D. 
Initially, field 130F reflects the value of the opening amount 
in field 130E. As electronic cash is spent, the value in field 
130F reflects the difference between the opening amount and 
the amount spent. The key-lifetime actually granted by 
server computer 100 is stored in key-lifetime.field 130J. The 
key-uselimit actually granted by server computer 100 is 
stored in key-use-limit field 1301. The value of label-value 
pair 4613A is stored in persona id field 130K. The date that 
the session was created is obtained from server application 
software 110 and stored in opening date field 130G. The 
value of label-pair 4617D is saved in the record note field 
130M. The remaining fields of server session data structure 
130 are discussed in the context of the CA-type messages 
below. . - 

After step 1509, message OS2 is assembled by and 
transmitted from server computer 100 to customer computer 
200 to complete credit session process 407. The contents of 20 
message OS2 is now described with reference to FIGS. 23A 
and 23B. 

Label-value pair 4713A has the label "id". The value of 
label-value pair 4713A indicates the persona id for customer 
user 203. The value of label-value pair 47 13 A is the same as 25 
that received in message OS1 in label-value pair 4613A. 

Label-value pair 4713B has the label "transaction". The 
value of label-value pair 4713B is a transaction number. The 
value of label-value pair 4713B is the same as that received 
in message OS1 in label-value pair 4613B. 

Label-valuepair 4713C has the label "date". The value of 
label-value pair 4713C is the same as that received in 
message OS1 in label-value pair 4613 C. 

Label-value pair 4713D has the label "service-category". 
The value of label-value pair 4713D is the same as that 
received in label-value pair 4613E of message OS1. 

Label-value pair 4717 has the label "opaque". The value 
of label-value pair 4717 includes the opaque section con- 
tents (in encrypted form) of message OS2. We now describe 
the opaque section contents of message GS2, shown in FIG. 
23B. 

Label-value pair 4717Ahas the label "type". The value of 
label-value pair 4717A references a record in message data 
structure 270 (FIG. 5A) which sets forth the labels of the . 
opaque section content of message 0S2. The value of 45 
label-value pair 4717A is obtained from server software 110. 

Label-value pair 4717B has the label "server-date". The 
value of label- value pair 4717B indicates the date and time 
message OS2 was assembled according to the clock of . 
server computer 100. 

Label-value pair 4717G has the label "response-code" and 
the value "success" or "failure" as previously described. 
Label-value pair 4717C indicates whether open session 
process 407 was a success or failure. 

Label-value pair 4717D has the label "swseverity" 
(software severity) and the value "fatal" or "warning". The 
value of label-value pair 4717D indicates whether customer 
application software 210 needs to be updated, but is still 
usable ("warning*') or is no longer usable ("fatal"). The 
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value of label-value pair 4717D is null if customer applica- 60 key of field 130B, 



Label-value pair 4717F has the label "message". The 
value of label-value pair 4717F is a free text message 
associated with an error or success condition returned in 
label-value pair 4717C and displayed to customer user 203. 
The value of label-value pair 4317F may include a message 
indicating a duplicate requested persona id, a bad digital 
signature or an ill formed message OS1 and instructions as 
to how customer user 203 should proceed (e.g., "call system 
administrator"). 

Label-value pair 4717G has the label "key-lifetime" and 
the value obtained from the key-lifetime of field 13 OJ (FIG. 
4L) indicating the maximum length of time the session will 
last 

Label-value pair 4717H has the label "key-use-limit" and 
the value obtained from the key-use-limit of field 1301 
indicating the maximum number of transactions which may 
occur during the session. 

Label-value pair 47171 has the label "amount" and indi- 
cated the maximum amount of electronic cash available to 
customer user 203 during the session. The amount value of 
label-value pair 47171 may be less than or equal to the 
amount requested by customer user 203 at step 1502. 
vLabel-value pair 4717J has the label "foreign-exchange" 
and a value mdicating a conversion rate from the currency 
denomination included in the value of label-value pair 42171 
into other currencies, for example, U.S. dollars into Cana- 
dian dollars. Preferably, the indicated conversion rate is in 
the number of minor units (or major units if there is no minor 
unit) of the destination currency for hundred major units of 
source currency. 

Label-value pair 4717K has the label "session-funds". 
The value of label-value pair 4717K indicates an amount of 
electronic cash sent to all open sessions including the 
amount value of label-value .pair 44171. A customer persona 
120.1 may have any number of sessions open. Label-value 
pair 4717K provides customer user 203 information regard- 
ing the amount of funds initially allocated to all open 
sessions, including the session just opened. 

Label-value pair 4717L has the label "balance". The value 
of label- value pair 4717L indicates the amount of electronic 
cash stored in cash container field 120G.2 of server persona 
data structure 120 for customer user 203 after the transfer of 
electronic cash funds to opening amount field 130E of server 
session data structure 130. 

Label-value pair 4717M has the label "on-hold". The 
value of label-value pair 4717M is obtained from cash 
container field 120G.3 and indicates the amount of uncol- 
lected electronic cash still being cleared in persona 120.1 for 
customer user 203. This value represents electronic cash 
which are awaiting approval or processing by the issuer of 
the instrument from which funds are being load or to which 
funds are being unloaded. 

Label-value pair 4717N has the label ^fee". The value of 
label-value pair 4717N indicates a fee charged to customer 
us?r 203, if any, associated with processing message OS1. 

Label-value pair 47170 has the label "session-id". The 
value of label-value pair 47170 is obtained from the session 
id of field 130A 

Label-value pair 4717P has the label "session-key". The 
value of label-value pair 4717P is obtained from the session 



tion software 210 is current. 

Label-value pair 4717E has the label "swmessage" 
(software message). The label- value pair 4717E indicates 
instructions as to what customer user 203 should do in the 
case of -a "fatal" or "warning" software severity. The value 
of label-value pair 4717E is only present if the value -of 
label-value pair 4717D is not null. 
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Label-value pair 4717Q has the label "session-salt". The 
value of label-value pair 4717Q is obtained from the session 
salt of field 130C. 

At step 1509 of FIG. 21, server software 100 assembles 
message OS2 according to the flow diagram of FIG. 12. 
Server message assembly procedure 1000 was described 
previously for the assembly of message R2. 
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At step 1509 A, message OS2 is sent (transmitted) from stored in field 265K The key-use limit from label-value pair 
server computer 100 to customer computer 200. 4717H is store in field 265J. The amount from label-value 

At step 1510, customer computer 200 receives message pair 47171 is stored in filed 2651. The balance from label- 
OS2 from server computer 100 and unwraps message OS2 value pair 4717L is stored in field 265P. The fee from 
by executing message unwrap procedure U00 for ^essage s ubel-vaiue pair 4717N is stored in field 2650. The session- 
UM. Message unwrap procedure 11UO (steps 1101-1121) id bom ^l-value pair 47170 is stored in field 265L. 
was previously descnbed for message R2 with reference to jf & open xss io a process is initiated by merchant user 
' ' 303, record 370.1 of merchant cash log data structure 370 is 

ai step 15U, updated as follows: 

(1) if an error flag was set at step 1105, the flag will be 10 ^ response code from label-value pair 4717C is stored 
detected at step 1511 and processing of message OS2 m field 370O . The message from label-value pair 4717F 
terminates at step 1512, From the perspective of cus- associated with the response code from label-value pair 
tomer user 203, no further action is taken with respect 4717C ^ saved in field 370T ^ sessk)I1 -id ^ label . 
to message OS2. In the present invention, a mechanism va i ue pair 47170 ^ stored m ficld 370s 
isprovidedwitlimcustomerappHcationsoftware210to 1S Processing continues at step 1517 where open session 
create and send to server computer 100 a message. This process 407 ends 

message includes the OS2 message as received by p. Transaction/Payment Process 409 
customer computer 200 and any diagnosis of what When customer user 203 and merchant user 303 have 
caused the message to fail. No response to this message opea sessions, secure cash transactions can occur over the 
If n L b l SerV " c ™P uter100 to customer computer 20 mtcrnet 5Q Security ^ ^ means ^ customer 

200. Rather, the- information is used to ascertain ^ 203 and merchant user 303 can each be confident that 
whether a problem exists within the system and if its electronic funds are not at risk of being accessed by an 
appropriate corrective measures need to be taken. unauthorized third party and that no electronic cash will be 

(2) if no error flag was set at step 1105 but an error in transferred until both parties have assented to a transaction 
message OS1 was detected at step 905, processing 25 which has been validated by server computer 100. 
continues at step 1513 where the content of label-value A transaction includes a customer user 203 shopping 
4717C is checked. If the value of label-value 4717C is among Internet 50 merchant users 303 who have merchant 
other than "success", error processing routines are personas 120.2. Using well known techniques, customer 
performed at step 1515 causing customer application user 203 and a merchant* user 303 agree on a price that 
software 210 to display the message contained in 30 customer user 203 is willing to pay for a product to be 
label-value 4717F associated with the content of label- provided by merchant user 303. When merchant user 303 
value 4717C and to interpret the value of label-value requests payment, customer user 203 elects to pay with 
4717C and take whatever action may be associated electronic cash. This election drives an exchange of mes- 
with that value; or sages resulting in the ultimate payment to merchant user 303 

(3) if message OS1 passed the check at step 905 and no 35 for the product purchased by customer user 203. 

flags were set at step 1105, processing continues at step FIGS. 24A-24C is a flow diagram depicting transaction/ 
1516 where customer application software 210 updates payment process 409 which begins at step 1701. 
customer database 202. "At step 1702A merchant computer 300 assembles mes- 

Customer session data structure 240 is updated as follows: sage PR1. Message PR1 preferably does not include 
The session id, is stored in the session id field 240A. The 40 encrypted data. Thus, only steps 814-817 of message assem- ' 
session key is stored in the session key field 240B^ The bly procedure 800 (FIG. 9) are needed to assemble message 
session salt is stored in the session salt field 240C The value PR1. The content of message PR1 is now described with 
of label-value pair 47171 includes a currency designator and . reference to FIG: 25. 

a quantity. The quantity value is stored in opening amount Label-value pair 5013Ahas the label "type". The value of 
field 130E and the currency designator associated with the 45 label-value pair 5013 A references a record in message data 
value stored in field 130E is stored in field 130D. The value . structure 270 (FIG. 5A) which sets forth labels comprising 
of label-value pair 4717G is stored in key-lifetime field PR1. The value of label-value pair 5013A is obtained from 
240K. The value of label-value pair 4717G is stored in merchant application software 310. 
key-use-limit field 240J. Label-value pair 5013B has the label "merchant-id". The 

It is noted that field 240F initially will reflect the value of 50 value of label-value pair 5013B indicates the persona id for 
the opening amount in field 240E. As electronic cash is merchant user 303. The value of label-value pair 5013B is 
spent, the value in field 240F will reflect the difference obtained from field 320A (FIG. 6Q. 
between the opening amount and the amount spent. The Label-value pair 5013C has the label "rherchant-order- 
remaining. fields of customer session data structure 240 are^ id". The value of label-value pair 5013C indicates an order 
discussed in the context of the CA-type messages below. 55 identification number ("order id") generated by merchant 

In addition to the values recorded in customer session data computer 300 to identify a particular order. Hie value of 
structure 240, record 265 of customer log data structure 260 label-value pair 5013C is stored in field 370C (FIG. 7Q. 
is updated as follows: The persona id from label-value pair Label-value pair 5013D has the label "merchant-date". 
4713Ais stored in field 265H. The transaction number from The value of label-value pair 5013D indicates the date and 
label-value pair 4713B is stored in field 265B. The- date from 60 time message PR1 was assembled according to the clock of 
label-value pair 4717B is stored in field 265C The response- merchant computer 300. 

code from label-value pair 4717C is stored in field 265F. The Label-value pair 5013E has the label "merchant 
software severity code from label-value pair 4717D is stored swversion" (merchant software version). The value of label- 
in field 265D. The software-message from label-value pair value pair 5013E indicates the version of merchant appli- 
4717E is .stored in field 2 65E. The response message asso- 65 cation software 310 communicating with customer 
dated with the response code from field 4717F is stored in computer 200. The value of label-value pair. 5013E is 
field 265G. The key-lifetime from label-value pair 4717G is ' obtained from merchant application software 310. 
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Label-value pair 5013F has the label "note". The value of key for merchant persona 120.2. The value of label-value 

label-value pair 5013F describes the product being provided pair 5013N may be stored by customer application software 

by merchant user 303 to customer user 203. The value of in the event that a dispute arises over the transaction. In such 

label-value pair 5013F is obtained by merchant application event, server computer 100 can use the value of label-value 

software 310 from software provided by merchant 303 or a 5 pair 5013N to determine if message PR1 was actually sent 

third-party. by merchant computer 300. 

Label-value pair 5013G has the label "merchant-amount". Referring again to FIG. 24A, step 1702A, a new record 

The value of label-value pair 5013G describes the currency 350.1 (FIG. 7A) is added (assembled) as follows: 

and the price for the product described in label-value pair The value of label-value pair 5013C (relating to the 

5013F. merchant-order-id) is stored in order-id field 350A 

Label-value pair 5013H has the label "accepts". The value The value of label-value pair 5013G (relating to the 

of label-value pair 5013H identifies credit cards accepted by amount that merchant user 303 intends to receive in 

merchant user 303 (if any). The values of label-value pair exchange for products) is stored in amount field 350B. 

5013H are obtained from merchant user 303. Transaction/payment process 409 continues at step 

Label-value pair 59131 has the label "url-pay-to"/ The 1702C. There, merchant computer 300 transmits message 

value of label-value pair 59131 is an Internet 50 uniform 15 PR1 to customer computer 200. Merchant computer 300 

resource locator. The Internet 50 uniform resource locator of waits for message CA1 from customer computer 200. 

label-value pair 59131 is the address on the Interne t':50 to At step 1702D, customer computer 200 receives message 

which customer computer 200 is to sends message CA4, PR1 from merchant computer 300 and unwraps message 

described later. PR1 by executing message unwrap procedure 3300. Mes- 

Label-value pair 5013 J has the label "url-cancel". The 20 sage unwrap procedure 3300 is now described with refer- 

value of label-value pair 5013 J is an Internet 50 uniform ence to FIG. 26, where it begins at step 3301. 

resource locator. The Internet 50 uniform resource locator of At step 3302, customer application software 210 extracts 

label-value pair 5013J is used by customer computer 200 the protocol (version) number of header 5005 of message 

should customer user 203 decide to cancel a transaction. PR1. Next, based upon the .extracted protocol number, 

Label-value pair 5013K has the label "url-success". The 25 message template data structure 270 (FIG. 5A) is accessed 
value of label-value pair 5013K is an Internet 50 uniform to deterrnine the expected format of message PR1. The 
resource locator which directs customer computer 200 to an expected format may include message syntax (e.g., permit- 
address on the world wide web if a transaction is successful. ted end-of-line characters) and message coding (e.g., ASCII 
The success of a transaction is reported in message CA4, or hex). Message PR1 is parsed in accordance with the 
described later. For example, if the transaction is validated 30 expected format as follows. 

by server computer 100, the value of label-value pair 5013K At step 3303, customer computer 200 calculates a check- 
may direct customer computer 200 to a web page that sum using the same data used by merchant computer 300. At 
congratulates customer user 203 for his or her purchase. step 3304A, the checksum calculated at step 3303 is com- 
Label-value pair 5013L has the label <( url-failure" . The pared to the checksum of trailer 5050 of message PRL If the 
value of label-value pair 5013L is an Internet 50 uniform 35 checksums are not equal, message PR1 is discarded at step 
resource locator which directs customer computer 200 to an 3304B where message unwrap procedure 3300 also termi- 
address on the world wide web if a transaction is unsuc- nates. 

cessful The failure of a transaction is reported in message If the checksums are equal at step 3304A, processing 
CA4, described later. For example, if the transaction is not continues at step 3304C where the message is checked to 
validated by server computer 100, the value of label-value 40 deterrnine if it is appropriate for message unwrap procedure 
pair 5013L may direct customer computer 200 to a web page 3300. If a message includes the label "type" in the trans- 
which requests customer user 203 to try his or her purchase parent part of the message and the value PR1, it is appro- 
agaux priate. If a message does not have this label-value pair, it is 
Label-value pair 5013M has the label "merchant-signed- not appropriate for a message unwrap procedure 3300 in 
hash-key". The value of label- value pair 5013M represents 45 which case processing continues at step 3304D where the 
a hash of the modulus part of the RSA public/private key message is diverted to another unwrap procedure, described 
pair used by merchant computer 300 to sign the hash of elsewhere. Message PR1 is appropriate; therefore, process- 
merchant-signed hash label-value pair 5013N described ing continues at stby refer where the message type is 
below. The value of label-value pair 5013M permits server deterrnined by reference to the value of label-value pair 
computer 100 to confirm that the RSApublic key maintained 50 5013 A In this case, the value of label-value pair is 
in field 120GC (FIG. 4E) for merchant persona 120.2 is the "payment-request." 

same key used to sign "merchant-agned-hash" label-value At step 3305 a form check of message PR1 is performed, 

pair 5013N, or if the decryption of label-value pair 5013N The form check procedure of step 3305 is software version 

fails, the reason for such failure. ^ dependent. That is, the expected form of the message, and 

Label-value pair 5013K has the label "merchant-signed- 55 the criteria that determine whether it is acceptable, depend 

hash". For message PR1, the value of label-value pair on me message and any variations of the message that are 

5013N is a hash of label-value pairs 5013A-5013M in that valid at a given time. At a minimum, the form check ' 

order. This hash is signed, meaning that the hash is hashed procedure will ascertain whether an incoming message 

again, then encrypted with the RSAprivate key for merchant contains all the labels that are prescribed for that message, 

persona 120.2. The RSAprivate key merchant persona 120.2 60 whether there are values for each label that requires a value, 

is obtained from field 320H (FIG. 6Q. and whether the values are of the type (e.g., text, signed 

Label-value pair 50130 has the label "merchant- numbers), syntax and within any specified limits as required. 

amount2". The value of label-value pair 50130 describes the . If there are additional labels, customer computer 200 will 

price in currencies other than that associated with the price ignore them. If a message cannot be parsed, or if it can be 

specified in label-value pair 5013G. '65 parsed but does not meet a form criteria, an error flag will 

Customer user 203 cannot authenticate the signature of be set at step 3306. In this case, message unwrap procedure 

label-value pair 5013N because it does not have the public 3300 ends at step 3309. 
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If message PR1 has proper form, processing continues at "payee-currency" and the value indicated by the currency 

step 3307. There, customer application software 210 adds portion of label-value pair 5013G of message PR1. The 

(updates) a new record 266 as follows: value of label-value pair 5U3E describes the currency in 

The merchant-id value of label-value pair 5013B is Stored which merchant user 303 intends to be paid for the trans- 

ih field 266A The merchant-order- id value, of label-value 5 action. 

pair 5013C is stored in field 266B. The amount value of Label-value pair 5113F has the label "note-hash". The 

label-value pair 5013G is stored in field 266C. The value of label-value pair 5113F is a hash of label-value pair 

merchant-note value of label-value pair 5013F is stored in 5013F of message PR1. 

field 266D. The pay-to-value of 50131 is stored in field ^^"7^ ?™ 5L f 3G ,A a S la ° el "payee-id" The 

20gp 10 value of label-value pair 5113G is the merchant persona id 

. Message unwrap procedure 3300 ends at step 3309. obtained from the value of label-value pair 5113B of mes- 

Referrmg again to , FIG. 24, at step 1703 customer com- ""f^^ pair 5U3H has me label « order -id» The 

puter 200 onlays the offer of merchant user 303 to cms- value of label ^ ue pair 5113H is the order id obtained from 

c^Vn^ T ^ t V *f ° ^ abcl - v ^ e 5013F the value of label^value pair 5113C of message PR1. 

5013G (descrying the product being sold to customer user 15 Label-value pair 51131 has the label "service-category". 

203 and the offer price) are displayed. ^ value of labe i. V alue pair 51131 is a label which may be 

At step 1704A,, customer user 203 accepts the offer of used by merchant computer 300 to route message CA1 to a 

merchant user 303. if is foreseeable that at this juncture, processor within merchant computer 300 that handles mes- 

customer user 203 will also be given a variety of payment sages of a particular service category, 

options (e.g., credit card or electronic cash). If customer user 20 At step 1624, customer application software 210 gen'er- 

203 selects credit, other processes will take place which are ates a 56-bit DES key DES-CA1 according to' CA-DES-key 

not described herein. If customer user 203 indicates a desire generation process 1600, shown in the flow chart of FIG. 29, 

to pay for the product with electronic cash, processing Generation of DES key DES-CA1 begins at step 1610. 

continues at step 1705. At step 1611, customer application software 210 con- 

At step 1705, customer application software 210 deter- 25 structs (calculates) a quantity Q, an eight byte quantity, 

mines whether customer user 203 has an open session by Quantity Q is a concatenation of the values of label-value 

searching records 240 (FIG. 5E). pairs 5113A, 5113B and 5113D of message CA1. It is 

If customer user 203 does not have an open session, preferred that the . resulting DES Key change with each 

processing proceeds to step 1706. There, a session is created message so as to increase the likelihood that each DES key 

using open session process 405 as described above. 30 generated by CA-DES-key generation process 1600 will be 

If customer user 203 has an open session, or after open unique. In the present invention, the value of session key 

session process 405 has been executed, processing continues field 240B and label-value pair 5113D ("index**), when 

at step 1707A. There, customer computer 200 assembles taken together, will normally be different for every request 

message CA1 as follows. message (that is, message CA1 and message CA2) and every 

Referring to FIG. 27, message assembly procedure CA12 35 response message (that is, message CA3 and message CA4). 

is depicted, ("CA12" references that this message assembly In addition, the value of label-value pair 5113 A ("type") will 

procedure is executed to assemble messages CA1 and CA2.) differentiate the request from the response, resulting a low 

Message assembly procedure CA12 for message CA1 probability that any two messages will be ; encrypted with the 

begins at step 1621. Message CA1 is shown in FIGS. 28A same DES key. Additional variability is obtained by using 

and 28B. ^ 40 label-value. pair 5113B ("version"). 

At step 1622, customer application software 210 accesses In the present invention, the concatenation of the value of 

message template data structure 270 (FIG. 5A) to obtain a label-value pairs 5113A, 5113B and 5113D of message CA1 

list of labels, which, when matched up with associated results in a four-byte quantity. To reach the desired value of 

values, make up the transparent label-value pairs eight-bytes, me resulting concatenation is padded on the left 

5U3A-5113I of message CA1. At step 1623, values are 45 side with four bytes of zeros. 

associated with each label. These label-value pairs are now At step 1612, a 64-bit initialization vector is obtained. The 

described. initialization vector is the lower 64-bits of the session-key of 

Label-value pair 5113A has the label "type". The value of field 240B (FIG. 5E). This initialization vector was gener- 

label-value pair 5113A references a record in message data ated during open session process 407. 

structure 150 (FIG. 4A) which sets forth the labels com- so At step 1613, a logical "exclusive or" (XOR) operation is 

prising message CA1. The value of label-value pair 5113A performed on quantity Q calculated at step 1611 and the 

is obtained from customer application software 210. initialization vector obtained at step 1612. 

Label-value pair 5113B has the label "version". The value At step 1614, the result of the XOR operation at step 1613 

of label-value pair 5U3B is a code maintained in message (a 64-bit value) is encrypted usin g the 56-bit DES key stored- 

data structure 270 (FIG. 5A) which references a record 55 in the upper 64-bits of the session-key of field 240B. The 

within the type record indicated by label-value pair 5113 A 56-bit DES key was generated during open session process 

The value of label -value pair 5113B is retrieved by customer 407. ' 

application software 210 from message data structure 270. At step 1615, the parity bits of the encrypted XOR result 

Label-value pair 5113C has the label "session-id". The of step 1614 are stripped. In this manner, the 56-bit DES key 

value of label-value pair 5113 C is obtained from the session- 60 DES-CA1 is created. . ■ 

id of field 240A (FIG. 5E). CA-DES-key generation process 1600 for message CA1 

Label-value pair 5113D has the label "index". The value ends at step 1617. 

of label-value pair 5113D is an integer assigned by customer Referring again to FIG. 27, message assembly procedure 

application software 210 to a transaction within a session CA12 for message CA1 continues at step 1625. There, the 

and represents a use of the session key stored in field 240B. 65 DES key DES-CA1 is stored (saved) in a temporary register. 

The range of values is bounded by 1 and the key-use-limit At step 1626, customer application software 210 accesses 

stored in field 240J. Label-value pair 5113E has the label message template data structure 270 (FIG. 5A) to obtain a 
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list of labels, which, when matched up with associated 
values, make up the opaque section contents of message 
CAl. 

The opaque section contents of message CA1 are shown 
in FIG. 28B where label-value pair 5117A has the label 
"amount". The value of label-value pair 5117 A describes the 
currency and the amount that customer user 203 intends to 
pay for the product. 

Label-value pair 5117B has the label "auth-code" and is 
created at step 1628. For message CA1, the value of label- 
value pair 5117B is a hash of the concatenation of the 
following: 8-byte salt of field 240C, the values of label-value 
pairs 5U3A, 5U3C-5113H, and 5117 A and the 8-byte salt 
of field 240C. Prior to hashing, all white space embedded in 
the values of label-value pairs 5113A, 5U3C-5U3H, and 
. 5U7A is removed and a vertical bar separator character 
inserted between each adjacent pair of values. 

This authentication code is not a digital signature. While 
a digital signature could be used instead of the auth-code 
reflected in label-value pair 5117B, the cost of such use in 
terms of processing time is substantial when compared to 
processing a hash. Given the safeguards provided by the use 
of independent sessions having limited duration for cus- 
tomer user 203 and a merchant user 303, the benefit of 
encryption-based non-repudiation is not sufficient to out- 
. weigh the cost in processor time. 

At step 1629, label-value pair 5117B, created at step 1628, 
is appended to label-value pair 5117A Label-value pairs 
5U7A and 5117B are encrypted using DES-key DES-CA1 
stored in the temporary register at step 1625. 

At step 1630, the data encrypted at step 1629 is encoded 
using well known techniques. 

Message GAL is assembled at steps 1631-1634. At step 
1631,' header 5105 is created using the message template 
found at customer message template data structure 270 
(FIG. 5A) and the protocol number as embedded in customer 
application software 210. 

At step 1632, the transparent label-value pairs 
5113A-5113H are appended. 

At step 1633, opaque label- value pair 5117 is appended. 
Label-value pair 5117 has the label "opaque" signifying that 
the value which follows is encrypted data. The value of 
label-value pair 5117 represents the data which was encoded 
at step 1630. 

Trailer 5150 is assembled at step 1634. The checksum of 
trailer 5150 is calculated as described above with respect to 
sample message 4000. Trailer 5150 is added to the remain- 
der of message CA1. 

The assembly of message CA1 is now complete. Message 
assembly procedure CA12 for message CA1 ends at step 
1635. 

Referring again to FIG. 24, processing continues at step 
1707 A There, customer computer 200 adds a new record 
253 (FIG. 51) as follows. 

Customer application software 210 creates a value, 
preferably, "cash-payment", and saves it at type field 253A 

Customer application software also creates a transaction 
number and date and stores them in transaction number field 
253B and date/time field 253C. - 

The software version of the customer application software 
210 used to create message CA1 is obtained from customer 
application software 210 and saved in software version field 
253D. 

The persona id for customer persona 120.1 is obtained 
from field 220A and stored in field 253E. 

The value of label-value pair 5013C from message PR1 is 
saved in order id field 253F. 
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The value of label-value pair 5013B is saved in merchant 
id field 253G. 

The value associated with label-value pair 5U7A is saved 
in amount field 253H and deducted from current value field 
5 240F of customer session data structure 240. 

User memo field 2531 stores an optional note (memo) 
from customer describing the transaction. The value of field 
2531 is obtained from customer user 203 in response to a 
prompt from customer application software 210 at the time 
10 customer user 203 agrees to make payment. 

The value of label-value pair 50131 from message PR1 is 
saved in field 2531 
A copy of message CA1 is preferably saved in field 253K. 
Referring again to FIG. 24A, processing continues at step 
15 1708. There, customer computer 200 transmits message 
CAl to merchant computer 300. Customer computer 200 
* awaits for a reply message CA4 from^rnsrchant computer 
300. 

At step 1709, merchant computer 300 receives message 
20 CA1 from customer computer 200 and unwraps message 
CA1 by executing message unwrap procedure CA1. Mes- 
sage unwrap procedure CA1 for message CA1 is now 
described with reference to FIG. 30 where it begins at step 
1641. 

25 At step 1642, merchant software 310 extracts the protocol 
number of header 5105 of message CA1. Next, based on the 
extracted protocol number of field 5105C, message data 
structure 380 is accessed to determine the expected format 
of message CA1. The expected format may include message 
30 syntax (e.g., permitted end-of-line characters) and message 
coding (e.g., ASCII or hex). Message CAl is parsed in 
accordance with the expected format as follows. 

At step 1643, merchant computer 300 calculates a check- 
sum using the same data used by customer computer 200 at 
35 step 1633 of message assembly procedure CAL2 (FIG. 27) . 
for message CA1. At step 1644, the checksum calculated at 
step 1643 is compared to the checksum of trailer 5150 of 
message CA1. If the checksums are not equal, message CAl 
is discarded at step 1644D where CA1 message unwrap 
40 procedure terminates. 

If the checksums are equal at step 1644, processing 
continues at step 1644B where the message is checked to 
determine if it is appropriate for message unwrap procedure 
CAl. A message is appropriate if it includes the label "type" 
45 in the transparent part of the message and the value indi- 
cating a message CAl. If a message does not include that 
label-value pair, it is not appropriate. If a message is 
inappropriate, processing continues at step 1664C where the 
message is diverted to another merchant unwrap procedure. 
50 Message CAl is appropriate; therefore processing continues 
at step 1644B where the message type is determined by 
reference to label-value pair 5113A. 

At step 1645, a form check of message CAl is performed. 
The form check procedure of step 1645 is software version 
55 dependent. That is, the expected form of the message, and 
the criteria that detennine whether it is acceptable, depend 
on the message and any variations of the message that are 
valid at a given time as determined by reference to message 
type and version information provided in message CAl and 
60 message data structure 380 as previously described. At a 
minimum, the form check procedure will ascertain whether 
an incoming message contains all the labels that are pre- 
scribed for that message, whether there are values for each 
label that requires a value, and whether the values are of the 
65 type (e.g., text, signed numbers), syntax and within any 
specified limits as required. If a message cannot be parsed, 
or if it can be parsed but does not meet a form criteria, an 
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error flag will be set at step . 1647. In this case, message value pair 5217.1B permits the sender of a message to advise 
unwrap procedure CA1 ends at step 1648. If message CA1 the recipient of the message what version of that message 
passes the form check at step 1645, processing continues at was sent and to instruct the recipient how to . parse and 
step 1646 where the value of label-value pair 5117 is saved process that version. Label-value pair 5217.1B advises 
in a temporary register. Message unwrap procedure CA1 is 5 server computer 100 of the form and content of the opaque 
complete at step 1648. label-value pair 5217.1. The value of label-value pair 

Referring again to FIG. 24, processing resumes at step 52i7.1B is obtained from merchant application software 
1710A If error flags were set at step 1647, processing 310. 

continues at step 1710B where merchant error processing The present invention preferably allows merchant corn- 
procedures are invoked. io puter 300 to submit "n" GA1 messages received from one or 

If no flags were set at step 1647, processing continues at more customer computers 200 to server computer 100 in a 
step 1711A There, merchant computer 300 assembles mes- single message CA2. In the current invention, the variable 
sage CA2 (FIG, 31A) according to message assembly pro- V is an integer ranging from 1 through 255. A different 
cedure CA12, shown in FIG. 27. Message assembly proce- range could be established depending on system capacity 
dure CA12 was previously described for message CA1 with 15 and other factors. Message CA2 is structured such that 
the following noted exception: DES-key DES-CA2 is gen- transparent label-value pairs 5113A-5113D and 
erated (rather than DES key DES-CA1) using CA-DES-key 5U3F-5113H of a received message CA1 are included in 
procedure 1600. The content of message CA2, as shown in opaque label-value pair 5217.1. For" each message CA2 
FIG. 31Ais as follows: submitted by merchant computer 300 to server computer 

Label-value pair 5213A has the label "type". The value of 20 100, message CA2 includes label-value pairs 
label-value pair 5213Areferences a record in server message 5217.lC-5217.il (corresponding to label-value pairs 1 
data structure 150 which sets forth the labels comprising 5U3A-5113D and 5113F-5113H) and 5217.1J. More spe- 
message CA2. The value of label-value pair 5213A is cifically: 

obtained from merchant application software 310. Label-value pair 5217.1C has the label "type n " and the 

Label-value pair 5213B has the label "version" and ref- 25 value of label-value pair 5117A. 
erences a , record relating to the type record as described Label-value pair 5217.1D has the label "subversion^ and 
above. The value of label-value pair 5213B contains infor- the value of label-value pair 5117B. 
mation regarding the form and content of label-value pairs Label-value pair 52171E has the label "payer-session- 
5213A, 5213C, 5213D, and 5213E and information to id,/' and the value of label-value pair 5117C. 
decrypt and parse label-value pairs 5217.1 and 52172. As 30 Label-value pair 5217.1F has the label "payer-index,," 
will be discussed later, additional information regarding the and.the value of label-value pair 5U7D. * 
form and content of label-value pairs 5217.1 and .5217.2 is Label-value pair 5217.1G has the label "note-hasty and 
provided in label-value pair 5217.1B. The value of label- the value of label-value pair 5U7F. 
value pair 5213B is retrieved by merchant application soft- Label-value pair 5217.1H has the label "payee-icy and 
ware 310 from message data structure 380 (FIG. 6A). 35 the value of label-value pair 5117G. 

Label-value pair 5213C has the label "session-id". The Label-value pair 5217.11 has the label "order-icy and the 
value of label-value pair 5213C is obtained from the session- value of label-value pair 5117H. 

id of field 340A (FIG. 6E). . Label-value pair 5217!J has the label "merchant- 

Label-value pair 5213D has the label "index". The value amount,,". The value of label-value pair 5217.1J is provided 

of label-value pair 5213D is an integer assigned by merchant 40 by merchant application software 310 and describes the 

application software 310 to a transaction within a session currency and the amount that merchant user 303 intends to 

and represents a use of the session key stored in field 240B. receive for the product. 

Label-value pair 5213E has the label "service-category". Referring again to FIG. 24, processing continues at step 

The value of label-value pair 5213E is a label which may be 1711B where merchant computer 330 updates its local data 

used to route message CA2 to a processor within server 45 structures as follows. 

computer 100 that handles messages of a particular service . A new record 350.1 is created in merchant amount data 
category. structure 350 for the "n" CA1 messages included in message 

Message CA2 includes merchant-opaque label-value pair CA2. The order id from label-value pair order-id-n is stored 

5217.1 and customer-opaque label-value pair 5217.2. Label- in field 350A. The merchant-amount from label-value pair 
value pairs 5217.1 and 5217 2 have the labels "merchant- 50 merchant-amount-n is stored in field 350B. 

opaque" and "customer-opaque", respectively, signifying Record 370.1 (FIG. 7Q is updated as follows, 
that the values which follow are encrypted data. The value Status field 370B is set to "attempt" by merchant appli- 
of label-value pair 5217.1 represents the data which was cation software 310. Merchant user 303 J s session-id from 
base-64 encoded at step 1630. The value of label-value pair label-value pair 5213C is stored in field 370G. The merchant 

5217.2 is the value of label-value pair 5117 (forwarded by 55 user 303' s index from label-value pair 5213D is stored in 
customer computer 200 in message CA1) and saved in the field 370H. The session-id of customer user 203 from 
temporary register at step 1646. label-value pair 5217.1E is stored in field 370D. The index 

The opaque section contents of message CA2 are shown of customer user 203 from label-value pair 5217.1F is stored 
in FIG. 31B where label-value pair 5217.1A has the -label in field 370E. The merchant currency is taken from the 
"type". The value of label-value pair 5217.1A references a 60 currency symbol value in label-value pair 5217.1J and saved 
record in message data structure 150 which sets forth the in field 3701. The amount merchant expects to be paid is 
labels of the opaque section contents of message CA2. The taken from the amount value in label-value pair 5217.1K and 
value of label-value pair 5217. 1A is obtained from merchant stored in field 370J. 

application software 310. Referring again to FIG. 24, processing continues at step 

Label-value pair 5217.1B has the label "version" and 65 1712. There, merchant computer 300 transmits message 
references a record within the type record referenced by CA2 to server computer 100. Merchant computer 300 waits 
label-value pair 5217.1A. As previously discussed, label- for a reply message CA3 from server computer 100. 
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At step 1713A, server computer 100 receives message If the session is valid, at step 1668C, the message type is 

CA2 from merchant computer 300 and saves a copy of the determined by reference to label-value pair 5217.1A. For 

value of label-value pair 5213D of message CA2 in index example, value of label-value pair 5217.1A for message 

field 130LL.1 (FIG. 4J) and a copy of message CA2 in field QA2 may be "cash-collection " 

130LL.2. At step 1713B, server unwraps message CA2 by 5 Processing continues at step 1669. There, server computer 

executing server message unwap procedure . 1660. Server 100 performs a check of the form of message CA2. The form 

begins at step 1661 ' ex P ected form of the message, and the catena 

ATstep 1662, server software 110 extracts the protocol - determ f e whether il * acceptable, depend on the 

number from field 5205C of header 5205 of message CA2. 10 messa S e ™ d ^ vanatl °°s °* the message that are valid at 

Next, based upon the extracted protocol number, message * a ^ ven ^ de tennined by reference to message type and 

data structure 150 is accessed to determine the expected v^ 1011 data structure 150 as previously described. At a 

formatof message CA2. The expected format may include minimum, the form check procedure will ascertain whether 

message syntax (e.g.,, permitted end-of-line characters) and an incoming message contains all the labels that are pre- 

message coding (e.g., ASCII or hex). Message CA2 is 15 scribed for that message, whether there are values for each 

parsed in accordance with the expected format as follows. l aDC * mat requires a value, and whether the values are of the 

At step 1663, server computer 100 calculates a checksum tyft e ~(ffe text, signed numbers), syntax and within any 

using the same data used by merchant computer 300 at step specified limits as required. If a message can be parsed but 

1633 of message assembly procedure CA12 for message does not meet a form criteria, server computer 100 will set 

CA2. At step 1664, the checksum calculated at step 1663 is 20 - an error flag at step 1681 and return an error code in message 

compared to the checksum of trailer 5250 of message CA2. CA3 (described below). In this case, server message unwrap 

If the checksums are not equal, message CA2 is discarded at procedure 1660 for message CAH, terminates at step 1682. 

step 1664A where server message unwrap procedure 1660 If message CA2 passes the form check at step 1669, 

terminates. processing continues at step 1670. 

If the checksums are equal at step 1664, processing 25 At step 1670, the authentication code of merchant user 
. continues at step 1665A where the message is checked to 303 represented by label-value pair 5217. IK is verified 
determine if it is appropriate for message unwrap procedure (check) as follows. Server software 110 obtains the 8-byte 
1600. A message is appropriate if it includes the label "type" salt of field 130CC. Server software 110 then accesses 
in the transparent part of the message and the value indi- message data structure 150 to determine which label-value 
eating a message CA2. If the message does not include this 30 pairs were hashed at step 1627 of message assembly pro- 
label-value pair, it is not appropriate and processing contin- cedure CA12 for message CA2 to compute the value of 
ues at step 1665B where the message is diverted to another label-value pair 5217.1K. Server software U0 then hashes 
unwrap procedure described elsewhere. Message CA2 is those same label-value pairs. The 8-byte salt of field 130CC 
appropriate; therefore, processing continues at step 1665 G. is added as both a prefix of and a suffix to the label-value 
There, the value of merchant-opaque label-value pair 5217.1 35 pairs before the hash is computed. Ihis hash value is 
is decoded. compared to the value of label-value pair 5217.1K. If the 

At step 1666, server software 110 independently gener- values differ, an appropriate error flag is set at step 1681. In 

ates DES key DES-CA2 independently from merchant com- this case, server message unwrap procedure 1660 for mes- 

puter 300, according to CA-DES-key generation process sage CA2 terminates at step 1682. If the values match, 

1600, described previously. 40 processing continues at step 1671. 

. At step 1667, the 56-bit DES key DES-CA2 generated by At step 1671, variable "n" is initialized to one. The value 

server computer 100 is stored in a temporary register. of variable "n", as described above, represents the n* CA1 

Processing continues at step 1668. There, merchant- message included in message CA2. 

opaque label-value pair 5217.1 is decrypted using DES key At step 1672, server software 110 generates DES key 
DES-CA2. . -45 DES-CA1, according to CA-DES-key generation process 

At step 1668A, the success or failure of the decryption of 1600. DES key DES-CA1 generated by server computer 100 

label-value pair 5217.1 is determined. If the decryption fails is stored in a temporary register. 

for any reason, an error flag is set at step 1681 and server At step 1673, customer-opaque label-value pair 5217.2 is 

message unwrap procedure 1660 terminates at step 1682. decrypted using DES key DES-CA1. 

If the decryption is successful, processing continues at 50 At step 1674, the success or failure of the decryption of 

step 1668B. There, server computer 100 determines whether label-value pair 5217.2 is determined. If the decryption fails 

merchant user 303 has a valid session open. Server computer for any reason, an error flag is set at step 1678 and process- 

100 obtains the session id number of merchant from label- ing continues at step 1679. There, it is determined if there are 

yalue pair 5213C. The session id is used to obtain merchant more CA1 messages to process. If so, processing continues 

record 130.2 for the session identified in label-value pair 55 at step 1680. If not, server message unwrap procedure 1660 

5213C. The opening date stored in field 130GG is then terminates at step 1682. 

compared with the date as detenriined by reference to server If the decryption of label-value pair 52172 is successful, 

computer 100's clock and the time that has elapsed since the processing continues at step 1675. <cr> At step 1675, if the 

creation of the session calculated. If the amount of time that merchant 303 has a valid open' session, server computer 100 

has elapsed since the creation of the session exceeds the 60 determines whether the customer user 203 associated with 

value in key-lifetime field 130JJ, the session is invalid. In the nth payment request included in message CA2 has a 

addition, if the value in index label-value pair 5213D valid session open. Server computer 100 obtains the session 

exceeds the value of the key-use limit stored in field 130II, id number of customer user 203 from label-value pair 5217.1 

the session use is invalid. If the session is invalid, a E. The session "is used to obtain customer- session, record 

session-closed flag is set at step 1681 and CA2 unwrap 65 130.1 for the session identified in label-value pair 5217.1 E. 

procedure terminates at step 1682 and payment process 1700 The opening date stored in field 130G is then compared with 

continues at step 1714. the date as determined by reference to server computer lOO's 
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clock and the time that has elapsed since the creation.of the tinues at step 1681. There, the type of error will cause an 
session calculated. The session is invalid if the amount of appropriate code to be associated with response-code label- 
time that has elapsed since the creation of the session value pair 5317.1C and a message to be associated with 
exceeds the value in key-lifetime field 130J. The transaction label-value pair 5317.1E. The level of detail detected by 
is invalid if the value in index label-value pair 5217. IF 5 error flags and reported in the response-code label-value pair 
exceeds the value of the key-use limit stored in field 1301. ^ a decision for the system administrator. For example, a 
If the session is invalid, a session-closed flag is set at step "failure" may be a "hard failure", that is, a failure of a subset 
1678 and processing continues at step i679. There, it is °^ k^ 1 ^ 5 f° r wm^h resubmission of the message would not 
determined whether there are more CA1 messages to pro- resu } t *° processing of the message (e.g., invalid format or 
cess. If so, processing continues at step 1680. If not, server 10 cl °sed). "Failure" could also encompass a failure 
message unwrap procedure 1660 terminates at step 1682 which can be c ^ ed ( a timeK)Ut ^cause of a temporary 
At step 1676, the authentication code of customer user of server computer 100). In the discussion which 
203 represented by label-value pair 5117B of message CA1 f °Uows, the term fa ^ will be used in its broad context. 

is verified as follows. Server software 110 obtains the 8-byte " Ei^V*" * ^ f^^f^ ^f^J 0 
«it of fi^H nnr Q*™r tU " y step 1716 where server computer 100 determines whether 

salt of field 130C. Server software 110 then accesses mes- 15 me checks at st im ^ ^ im f the p 

^^^^^"^ m ^ T S ^ UCSl ^ges caused anerror flag to be set at stepS 

were hashed at step 1627 of message assembly procedure *lf jhe nth CA1 message caused a flag to be set, at step 1717 
«?™ C ? age J° com P utc ^ value of ^el-value the value of label-value pair 5317.1K (response-code-n)and 
pair 5117B. Server software 110 then hashes those same label-value pair 5317.2A (response code) will be set to 
label-value pairs. The 8-byte salt of field 130C is added as 20 failure; and label-value pair 5317.1N (problem-n)~and label- 
both a prefix of and a suffix to the label-value pairs before value pair 5317.2E problem) will assigned a value of a code 
the hash is computed. This-hash value is compared to the associated with the value of label-value pair 5317.1IC If the 
value of label-value pair 5117B. If the values differ, an operator of server computer 100 deems it desirable, a free 
appropriate error flag is set at step 1678 and processing ' form message regarding the failure can be included in 
continues at step 1679. There, it is detennined if there are 25 label-value pair 5317.1L (remark-n) and label-value pair 
more CA1 messages to process. If not, server message . 5317.5A (remark). 

unwrap procedure 1660 terminates at step 1682. If so, At step 1718A, server computer 100 assembles message 
processing continues at step 1680. If the values match at step CA3 according to server message assembly procedure 3400, 
1675, processing continues at step 1676. . shown in FIG. 33. 

If customer user 2 03's session is valid, processing con- 30 Server message assembly procedure 3400 for message 
tinues at step 1667. - CA3 begins at step 3401. 

At step 1677, payment to merchant user 303 is effected. At step 3402A, server software 110 accesses message 
For customer user 203, this, means deducting the amount type and version data structure 150 to obtain a list of labels, 
reflected in amount label-value pair 5217.2A from the cur- which, when matched up with associated values, make up 
rent amount of field 130F and capturing transaction data 35 the transparent label-value pairs 5313A-5313E for message 
130N of record 130.1. Transaction data 130N is shown in . CA3, shown in FIGS. 34A and 34B. At step 34Q2B, values 
FIG. 41 where the following data is captured: The amount in are associated with each label as follows, 
label-value pair 5217.2A is stored in field 130N.1; the Label-value pair 5313Ahas the label "type". The value of 
. customer session-id from label-value pair 5217.1E is stored label-value pair 5313A references a record in message data 
in field 130N.2; the order-id from label-value pair 5217.11 40 structure 380 which sets forth the labels of message CA3. 
is stored in field 130N.3; the merchant session-id from The value of label-value pair 5313A is obtained from server 
label-value pair 5213C is stored in filed 130N.4; and the software 110. 

customer index from label-value pair 5217.1F is stored in Label-value pair 5313B has the label "version" and ref- 
field 130N.5. erences a record relating to the record referenced by label- 

For merchant user 303, this payment means adding the 45 value pair 5313A. As previously discussed, label-value pair 
amount reflected in amount field 5117A to the current 5313B permits the sender of a message to advise the 
amount of field 130FF and capturing transaction data 1 recipient as to the version of that message and how to parse 
30NN of record 130.2.130.1. Transaction data 130NN is and process that version. Because message CA3 is in 
shown in FIG. 4K where the'following data is captured: The response to message CA2 sent by merchant computer 300, 
amount in label-value pair 5217.2A is stored in field 50 the version of message CA3 will be selected by server 
130NN.1; the customer session-id from label-value pair software 110 to assure that it can be processed by merchant 
5217.1E is stored in field 130NN.2; the order-id from application software 310. Label-value pair 5313B advises 
label-value pair 5217.11 is stored in field 130NN3; -the merchant application software 310 of the form and content 
merchant session-id from label-value pair 5213C is stored in of the transparent labei^value pairs 5313A, 5313C, 5313D, 
filed 130NN.4; and the merchant index from label-value pair 55 and 5313E. The value of label-value pair 5313B is obtained 
5213D is stored in field 130NN.5. from merchant application software 310. 

At step 1679, server software 110 deterrnines whether Label-value pair 5313C has the label "session-id". The 
message CA2 includes additional messages CA1 to be valiieof label-value pair 5313C is obtained from the session- 
processed. If there are additional CA1 messages to be id of field 130AA of merchant session data structure 130. 1 
processed, variable "n" is incremented at step 1680 and 60 Label-value pair 5313D has the label "index". The value 
processing continues at step 1672 as previously described. If of label-value pair 5313D is obtained from the index of field 
there are no additional CA1 messages to process, server 130LL of merchant session data structure 1302 
message unwrap procedure 1660 for message CA2 tenni- Label-value pair 5313E has the label "service-category", 
nates at step 1682. The value of label-value pair 5313E is a label which may be 

Processing continues at step 1714 of FIG. 24. There, if 65 used by merchant computer 300 to route message CA3 to a 
error flags were set at step 1681 as a result of the checks of processor within merchant computer 300 that handles mes- 
steps 1664, 1668A, 1668B, 1669, or 1670, processing con- sages of a particular service category. 
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At step 3402C, server software 10 generates 56-bit DES Label-value pair 5317.1L has the label "remark„". If the 

keys DES-CA3-C-Q and DES-CA3-M. DES keys DES- response-code value of label-value pair 5317.1K has other 

CA3-C-n and DES-CA3-M will be used to encrypt data to than a "success" value, the value of label-value pair 5317.1L 

be received by customer computer 200 and merchant com- is a free form text message providing a detailed explanation 

puter 300, respectively. DES keys DES-CA3-C and DES- 5 of the reason for the non-success. The value of label-value 

CA3-M are generated according to CA-DES-key generation pair 5317.1L is obtained at step 1717 described above from 

process 1600, previously described. server software 110. Label-value pair 5317.1M has the label 

Referring again to FIG. 33, message assembly procedure "collected-amount,," and the value indicating the amount of 

CA3 continues at step 3402D. There, DES keys DES-CA3- ' electronic cash collected by merchant user 303 for the 

C-n and DES-CA3-M are stored in temporary registers. 10 transaction (at step 1677 of server message unwrap proce- 

At step 3403, server software 10 accesses message tern- dure 1660 for message CA2). 

plate data structure 150 to obtain a list of labels, which, Label-value pair 5317.1N has the label "problem,,". If 

when matched up with associated values, make up the value of label-value pair 5317. IK has other than a "success" 

merchant-opaque section contents of message CA3 (FIG. value, the value of label-value pair 5317.1N is" a code 

34B). Values are associated with each label as follows. 15 advising customer user 203 as to the cause for the non- 

The merchant-opaque section contents of message CA3 success. The value of label-value pair 5317.1N is obtained 

are shown in FIG. 34B where, label-value pair 5317.1A has at step 1717 described above from server software 11& ■■. 

the label ''subtype". The value of label-value pair 5317. 1A Label-value pair 5317.10 has the label "order-id,,", lie 

is a label referencing a record in message data structure 380 value of label-value pair 5317.10 is obtained from label- 

which includes the labels of the merchant-opaque, section 20 value pair 5217.11 of message CA2. 

contents for message CA3. The value of label-value pair Label-value pair 5317.1P has the label "request-version". 

5317.1A is obtained from server software 110. The value of label-value pair 5317.1P represents the version 

Label-value pair 5317.1B has the label "subversion". The of message CA2 actually processed by server computer 100. 

value of label-value pair 5317.1B is a code maintained in <cr> Referring again to FIG. 33, at step 3405, an authenti- 

message data structure 150 which permits processing varia- 25 cation code for the merchant-opaque section of message 

tions of a message type as are valid at a given time. CA3, represented by label-value pair 5317.-1Q of FIG. 34B, 

Label-value pair 5317.1C has the label "response-code" is created. Label-value pair 5317.1Q has the label "auth- 

and the value "success" or "failure" as previously described. code". The value of label-value pair 5317.1Q represents the 

Label-value pair 53 17.1C indicates whether the transaction authentication code of server computer 100. For the 

presented to server computer 100 by message CA2 was a 30 merchant-opaque section of message CA3, the value of 

success, failure, etc. Hie value of label-value pair 5317.1C label-value pair 5317.1Q is an MD5 hash of the concatena- - 

is obtained at step 1715 described above from server soft- tion of the following: 8-byte salt of field 130CC, label-value 

ware 110. pairs 5313A-5313E and 5317.1A-5317.1P, and the 8-byte 

Label-value pair 5317.1D has the label "fee". The value salt oL field 130CC. Prior to hashing, all white space 

of label-value pair 5317.1 D indicates a fee charged to 35 embedded in label-value pairs 5313A-5313E and 

. merchant user 303, if any, associated with processing mes- 5317.1A-5317.1P is removed. 

sage CA2. The value of label-value pair 5317. ID is obtained At step 3406, label-value pair 5317.1Q, created at step 

from server software 110. . 3405, is appended to label-value pairs 5317.1A-5317.1P. 

Label-value pair 5317. IE has the label "problem". If the ' Label-value pairs 5317.1A-5317.1Q are encrypted using the 

response-code value of label-value pair 5317.1C has other 40 56-bit DES key DES-CA3-M. 

than a "success" value, the value of label-value pair 5317.1E At step 3407, data encrypted at step 3406 is encoded using 

is a code advising merchant user 303 as to the cause for the well known techniques. 

non-success. Hie value of label-value pair 53 17. IE is At step 3408, server software 110 accesses message 

obtained at step 1715 described above from server software template data structure 150 to obtain a list of labels, which, 

HO- 45 when matched up with associated values, make up the 

Label-value pair 5317.1F has the label "remark". If the customer-opaque section contents of message CA3. At step 

response-code value of label-value pair 5317.1C has other 3409, the customer opaque section is assembled. Values are 

than a "success" value, the value of label-value pair 5317. IF associated with each label as follows, 

is a free form text message providing a detailed explanation The customer-opaque section contents of message CA3 

. of the reason for the non-success. Hie value of label-value 50 are shown in FIG. 34 where label-value pair 53172Ahas the 

pair 5317.1F is obtained at step 1715 described above from label "response-code" and the value "success" or "failure", 

server software 110. Label-value pair 5317.2A indicates whether the transaction 

Message CA3 includes the following label-value pairs presented to server computer 100 by message CA2 was a 

5317.1G-5317.1P for each of the V CA1 messages sub- success, failure, etc. The value of label-value pair 5317 2A 

mitted with message CA2: - 55 is obtained in step 1717 described above from server soft- 

Label-valuepair5317.1G has the label "subtype/' and the ware 110. 

value of label-value pair 5217.1C of message CA2. Label-value pair 5317.2B has the label "remark". If the 

Label-value pair 5317.1H has the label "subversion,," and response-code value of label-value pair 5317 .2A has other 

the value of label-value pair 5217.1D of message CA2; . than a "success" value, the value of label-value pair 5317.2B 

Label-value pair 5317.11 has the label "payer-session,," 60 is a free form text message providing a detailed explanation 

and the value of label-value pair 5217.1E of message CA2. of the reason for the non-success. The value of label-value 

Label-value pair 5317.1J has the label "payer-index,," and pair 5317.2B is obtained at step 1717 described above from 

the value of label-value pair 5217.1F of message CA2. server software 110. 

Label-value pair 5317.1K has the label "response-code,," Label-value pair 53 17.2C has the label "foreign- 
and the value "success" or "failure" as previously described, 65 exchange". The value of label-value pair 53172C provides 

The value of label-value pair 5317.1K is obtained at step updated information regarding a conversion rate from the 

1717 described above from server software 110. • currency denomination included in the value of label-value 
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pair 5117A into other currencies. The value of label-value At step 2072, merchant software 310 extracts the protocol 

pair 5317 is obtained from server software 110. number from header 5305 of message CA3. Next, based 

Label-value pair 5317.2D has the label "amount" and a upon the extracted protocol number, message data structure 

vdue indxcating the amount of funds charged to customer 380 is accessed to determine the expected format of message 

2°3 for me transaction. The value of label-value pair 5 CA3. The expected format may include message syntax 

$3 } ^ ^ 5 £T™ e r r .f ^f- 110 ;, x, , (**■ P ermitted end-of-line characters) and message coding 
Label-value pair 5317 2E has the label "problem". If me ^ ^ or hex) Messa CA3 J ^ m a ^ rdan( | 

response-code value of ^label-yalue pan- 5317JZA has other ^ the expected format as foUows. : 

than a "success" value, the value of label-value pair 5317.2E A ♦ JLn ± * * i i , . , 

is a code advising customer user 203 as to the cause for the At stcp 2 f 3 ' mer f hant ^ m P* er 300 calculates a check- 

non-success. The value of label-value pair 5317.2E is 10 sum ^mg the same data used by server computer 100 at step 

obtained at step 1717 described above from server software 341 7 of messa S e assembly procedure 3400 for message 

]2o. CA3. At ste P 2074, the checksum calculated at step 2073 is 

Label-value pair 5317.2F has the label "order-id". The compared to the checksum of trailer 5350 of message CA3. 

value of label-value pair 5317.2F is obtained from label- If me checksums are not equal, message CA3 is discarded at 

value pair 5217.11 of message CA2. 15 step 2074A where* message unwrap procedure CA34 termi- 

Label-value pair 5317.2G has the label "request -version", nates. 
The value of label-value pair 5317 .2G represents the version If the checksums are equal at stef^ 2074, processing 
of message CA1 actually processed by server computer 110. continues at step 2075A where the message is checked to 
<cr> Referring again to FIG. 33, at step 3410, an authenti- determine if it is appropriate for message unwrap procedure 
cation code for the customer-opaque section of message 20 CA34. A message is appropriate if it includes the label 
CA3, represented by label-value pair5317.2H of FIG. 34C, "type" in the transparent part of the message and the value 
is created. Label-value pair 5317-2H;has the label "auth- indicating a message CA3 or CA4. If a message does not 
code". The value of label- value pair 5317.2H shown in FIG. include this label-value pair, it is inappropriate. Processing 
34C represents the authentication code of server computer of inappropriate message occurs at step 2075B where the 
100. For the customer-opaque section of message CA3, the 25 message is diverted to another unwrap procedure described 
value of label- value pair 5317.2H is a hash of a concatena- elsewhere. Message CA3 is appropriate; therefore, process- 
tion of the following: 8-byte salt of field 130C, the values of ing continues at step 2076 where the value of merchant- 
label-value pairs 5313A-5313D and 5317.2A-5317.2G, and opaque label- value pair 5317.1 is decoded, 
the 8-byte salt of field 130C. Prior to hashing, all white space At step 2077, merchant application software 310 gener- 
embedded in the values of label-value pairs 5313A-5313D 30 ates the same DES key DES-CA3-M generated by server 
and 5317.2A-5317.2G is removed and a vertical bar sepa- software 10 according to CA-DES-key generation process 
rator character inserted between each adjacent pair of values. 1600. 

At step 3411, label-value pair 5317 JH, created at step At step 2078, DES key DES-CA3-M is stored in a 

3410, is appended to label-value pairs 5317.2A-5317.2G/ temporary register. 

Label-value pairs 5317.2A-5317.2H are encrypted using 35 At step 2079, DES key DES-CA3-M is used to decrypt 

DES key DES-CA3-C-n. the value of merchant-opaque label-value pair 5317.1. 

At step 3412, data encrypted at step 3411 is encoded using A check of message CA3 is then performed at step 2080 

well known techniques (preferably base 64). as follows. 

Message CA3 is assembled at steps 3413-3417. At step At step 2080, the success or failure of the decryption of 

3413, header 5305 is created using the message template 40 label-value pair 5317.1 is determined. If the decryption fails 

found at type and version data structure 150 and the protocol for any reason, an error flag is set at step 2084 and message 

- number as embedded in server software 110. unwrap procedure CA34 terminates at step 2085. 

Next, at step 3414, transparent label- value pairs If the decryption is successful, at step 2080A, the message 

5313A-5313D are added (appended). Label-value pairs type is determined by reference to label-value pair 5317.1A. 

5213A-5213D were described previously. 45 For example, value of label-value pair 5317.1Afor message 

At steps 3415 and 3416, merchant-opaque label-value CA3 may be "cash-batch-receipt." 
pair 5317.1 and customer-opaque label-value pair 5317.2 are Processing continues at step 2081. There, merchant corn- 
appended. Label-value pairs 5317.1 and 53172 have the purer 300 performs a check of the form of message CA3. 
labels "merchant-opaque" and "customer-opaque", The form check procedure of step 2081 is software version 
respectively, signifying that the values which follow are 50 dependent. That is, the expected form of the message, and 
encrypted data. The value of label-value pair 5317.1, rep- the criteria that determine whether it is acceptable, depend 
resents the data which was encoded at step 3407. The value , on the message and any variations of the message that are 
of label-value pair 5317.2 represents the data which was valid at a given time as determined by reference to message 
encoded at step 3412 (which will be forwarded to customer type and version information provided in message CA3 and 
computer 200 in message CA4). 55 message template structure 380 as previously described. At 

Trailer 5350 is assembled at step 3417. The checksum of a minimum, the form check procedure will ascertain whether 

trailer 5350 is calculated as described above with respect to an incoming message contains all the labels that are pre- 

sample message 4000. Trailer 5350 is added (appended) to scribed for that message, whether there are values for each 

the remainder of message CA3. - — labels that requires a value, and whether the values are of the 

The assembly of message CA3 is complete. Message 60 type (e.g., text, signed numbers), syntax and withiri any 

assembly procedure 3400 for message CA3 ends at step specified limits as required. If a message cannot be parsed, 

.3419. or can be parsed but does not meet a form criteria, merchant 

At step 1719, merchant computer 300 receives message computer 300 will set an error flag at step 2084 and message 

CA3 from server computer 100 and unwraps message CA3 unwrap procedure CA34 terminates at step 2085. 

by executing message unwrap procedure CA34. Message 65 If message CA3 passes the form check at step 2081, 

unwrap procedure CA34 for message CA3 is now described processing continues at step 2082. There, the authentication 

with reference to FIG. 35, where it begins at step 2072. code represented by label-value pair 5317.1P is verified as 
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follows. Merchant software 310 obtains the 8-byte salt of message CA4. The value of label-value pair 5413A is 
field 340C (FIG. 6E). Based on the value of subtype label- obtained from merchant application software 310. 
value pair 5317.1A and subversion label- value pair 5317.1B, Label-value pair 5413B has the label "version" and ref- 
merchant application software 310 accesses message tern- erences a record relating to the record referenced by label- 
. plate data structure 380 to determine which label-value pairs 5 value pair 5413 A. As previously discussed, label-value pair 
. were hashed at step 3405 of message assembly procedure 5413B permits the sender of a message to advise the 
CA3 to compute the value of label-value pair 5317. EP. recipient as to the version of that message how to parse and 
Merchant application software 310 then adds the 8-byte salt * process that version. Because message CA4 is in response to 
of field 340C as both a prefix of and a sufllx to the values of ' message CA1 from customer user 203, the version used by 
those same label-value pairs and computes the hash of the 10 merchant application software 310 to construct message 
result. This hash value is compared to the value of label- CA4 will be selected by merchant application software 310 
value pair 5317.1Q. If the values differ, an appropriate error to assure that it can be processed by customer application 
flag is set at step 2084. Message unwrap procedure CA34 software 210. Label--value pair 5313B advises customer 
terminates at step 2085. application software 210 of the form and content of both the 

Referring again to FIG. 24, processing continues at step 15 transparent label-value pairs 5413A, 5413C and 5413D and 
1720. There, the opaque label-value pair 5417. The value of label-value 

(1) itan, error flag was set at step 2084, the flag will be * -pair 5413B is obtained from merchant application software 
detected at step 1720 and processing of message CA3 . 310. " 

will terminate at step 1721. Label-value pair 5413C has the label "session-id" and a 

(2) if no error flag was set at step 2084 but an error in 20 value mcUcating the current session id for customer user 203. 
message CA2 was detected at step 1681, processing Merchant computer 300 obtains the value of label-value pair 
will continue at step 1722 where the content of label- 5413C from the session -id value of label-value pair 5113C • 
value pair 5317.1C is checked. If the value of label- of message CA1. 

value 5317.1C is other than "success", error processing Label-value pair 5413D has the label "index". The value 
routines are performed at step 1723 causing merchant 25 of label- value pair 5413D is an integer selected from a range 

application software 310 to display the message con- of unused values indicating each time different transactions 

tained in label-value 5317.1F associated with the con- with a session is attempted. Merchant user 303 obtains the 

tent of label-value 5317. 1C. Merchant application soft- value of label-value pair 5413D from the index value of 

ware 310 will also interpret the value of label-value label-value pair 5113D of message CA1. 

5317.1E and take whatever action may be associated 30 Label-value pair 5413F has the label "order-id". The 

. with that value and CA3 message processing ends at value of label -value pair 5413F indicates the order identi- 

step 1733; or fication number generated by merchant computer 300 to 

(3) if message CA3 passed the check at step 1720 and step identify the order. The value of label-value pair 5413F is the 
1722, processing continues at step 1724 where mer- same ^ that provided in label-value pair 5013C of message 
chant computer 300 updates local data structure as 35 PR1« 

follows. Label-value pair 5413G has the label "service-category". 

Record 350.1 (FIG. 7A) is updated to reflect whether a The vaiue of label- value pair 5413G is a label which may be 

payment request was paid. Field 350C contains a flag which used by customer computer 100 to route message CA4 to, a 

is set to either "paid" or "not-paid", depending on whether, processor within customer computer 200 that handles raes- 

the response-code from label-value pair -5317.1C is "sue- 40 sages of a particular service category, 

cess" or "failure". Similarly, record 370.1 (FIG. 7C) is At step 3104, opaque label-value pair 5417 is appended, 

updated to reflect the status of a particular payment request. Label-value pair 5417 has the label "opaque" signifying that 

Field 370B, which is set to "attempt" at the time a particular . the value which follows is encrypted data. The value of 

payment request is sent to server computer 100 in message label-value pair 5417 represents the value of label-value pair 

CA2, is set to "success" or "failure" depending on whether 45 53172, forwarded from server computer 100 to merchant 

the response-code from label-value pair 5317.1C is "sue- computer 300. 

cess" or "failure". The result code from label- value pair Trailer 5450 is assembled at step 3105. The checksum of 

5317.1E is stored in field 370M. The fee paid by merchant trailer 5450 is calculated as described above with respect to 

user 303 for processing of the payment request from label- sample message 4000. Trailer 5450 is added (appended) to 

value pair 5317.1D is stored in field 370L. The amount 50 the remainder of message CA4. 

collected by merchant user 303 for a particular payment The assembly of message CA4 is now complete. Message 

request from label-value pair 5317.1M is stored in field assembly procedure 3100 ends at step 3106. 

370K and is added to field 360F of record 360.1 of sales Referring again to FIG. 24, processing continues at step 

session data structure 360. ■ *^ 1726. There, merchant computer 300 transmits message 

At step 1725, merchant computer 300 assembles message 55 to customer computer 200. 

CA4 according to message assembly procedure 3100, shown At step 1727, customer computer 200 receives message 

in FIG. 36. Message CA4 is shown in FIGS. 37A and 37B. CA4 from merchant computer 300 and unwraps message 

■ Message assembly procedure 3100 for message CA4 CA4 by executing message unwrap procedure CA34. Mes- 

begins at step 3101. At step 3102; header 5405 is created sage unwrap procedure CA34 for message CA4 was previ- 

using the message template found at message data structure 60 ously described for message CA3 with reference to FIG. 35. 

380 and the protocol number protocol as embedded in Referring again to FIG.- 24, processing continues at step 

merchant application software 310. 1728/ There, 

Next, at step 3103, transparent label-value pairs (1) if an error flag was set at step 2084, the flag will be 

5413A-5413G are added (appended). detected at step 1728 and processing of message CA4 

Label-value pair 5413Ahas the label "type". The value of 65 will terminate at step 1729; or 

label-value pair 5413 A references a record in message data (2) if no error flag was set at step 2084 but an error in 

structure 270 (FIG. 5A) which sets forth the labels of message CA1 was detected at step 1678, processing 
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will continue at step 1730 where the content of label- 
value pair 5417A is checked. If the value of label-value 
5317A is other than "success", error processing rou- 
tines are performed at step 1731 causing customer 
application software 210 to display the message con- 
tained in label-value 5417B associated with the content 
of label-value 5317.1C. Customer application software 
210 will also interpret the value of label-value 5417E 
and take whatever action may be associated with that 
value and processing message CA4 will -terminate at 
step 1733; or 

(3) if message CA4 passed the check at step 1728 and step 
1730, processing continues at step 1732 where cus- 
tomer computer 200 updates its data structures as 
follows. 

Customer computer 200 compares the value contained in 
label-value pair 54171!) with the value of label- value pair 
5117A If the values are different, customer computer 200 
adjusts the current amount field 240D to reflect the amount 
actually deducted from current amount field 130F as main- 
tained by. server computer 100. In addition to the values 
recorded in customer session data structure 240, a new 
record 263 of customer log data structure 260 is created as 
follows: The date from label-value pair 5413E is stored in 
field 263C. The response-code from label-value pair 5417A 
is stored in field 263D. The remark from label-value pair 
5417B associated with the response code from label-value 
pair 5417A is stored in field 263E. The amount from 
label-value pair 5417D is stored in filed 263J. The order-id 
from label-value pair 5417F is stored in field 263G. The 
session-id from label-value pair 5413C is stored in field 
263L. The index from label-value pair 5413D is stored in 
field 263M. 

G. Close Session Process 411 

Close session process 411 may be used by customer user 
203 to close a session. 

FIG. 38 depicts a flow diagram illustrating close session 
process 411 which begins at step 1801. 

At step 1802, customer application software 210 prompts 
(requests) customer user 203 to enter the identification 
number of the session to be closed, any record-note to be 
attached to a session, and whether customer user 203 desires 
a log of transactions submitted to server computer 100 by 
merchant 303 for customer user 203 during the session that 
is being closed. If customer user 203 has more than one 
session open, the prompt will include a list of all open 
sessions and request customer user 203 to select the session 
to close. 

The content of message CS1 is now described with 
reference to FIGS. 39A and 39B. 

Label-value pair 4813A has the label "id". The value of 
label-value pair 4813 A indicates the persona id for customer 
user 203. The value of label-value pair 4813A is obtained 
from field 220A (FIG. 5G). ^ 

Label-value pair 4813B has the label "transaction". The 
value of label-value pair 4813B is a transaction number, 
generated by customer application software 210, which 
uniquely identifies message CS1. The value of label-value 
pair 4813B allows server computer 100, upon receipt of 
message CS1, (1) to*send an associated reply -message CS2, 
described below, and (2) to deterrnine if message CS1 is a 
duplicate message (i.e., already received by server computer - 
100). The value associated with label-value pair 4813B is 
stored in field 256B. 

Label-value pair 4813C has the label "date". The value of 
label-value pair 4813C indicates the date and time that 
message CS1 was assembled and sent to server computer 
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100, according to the clock of customer computer 200. The 
value associated with label -value pair 4813 C is stored in 
field 256C. 

Label-value pair 4813D has the label "serverkey". As 
5 previously described, the DES key/IV pair used by customer 
computer 200 to encrypt the opaque label-value pair 4817 of 
message CS1 is encrypted using an RSApublic key of server 
computer 100. Label-value pair 4813D points, to the corre- 
sponding RSA private key as stored in server private key 
1(J data structure 160. 

Label-value pair 4813 E has the label "service-category". 
. Hie value of label-value pair 4813E is a label which may be 
used by server computer 100 to route message CS1 to a 
processor within server computer 100 that handles messages 
of a particular service category. 
15 Label-value pair 4817 is described next. Label-value pair 
4817 has the label "opaque" signifying that the value which 
follows is encrypted data. The value of label-value pair 4817 
represents the data which was encoded at step 813. The 
opaque section contents of message CS1 (FIG. 39B) is as 
20 follows: 

Label-value pair 4817Ahas the label "type". Label -value 
pair 4817 A references a record in message data structure 150 
which sets forth the labels of the opaque section contents 
message CS1. The value of label-value pair 4817A is 
25 obtained from customer application software 210 which, 
generates the label when customer user 203 initiates close 
session process 411. 

Label-value pair 4817B has the label "server-date". The 
value of label- value pair 4817B indicates the date and time 
30 message CS1 was assembled. This date and time is customer 
computer 200*s perception of server computer 100's clock. 

Label-value pair 4817C has the label "swversion" 
(software version). The value of label-value pair 4817C 
indicates the version of customer application software 210 
35 communicating with server computer 100 and is obtained 
from data embedded in customer application software 210. 
The value associated with label -value pair 4817C is also in 
field 256D. 

Label-value pair 4817D has the label "record-note". The 
40 value of label-value pair 4817D is an optional short text note 
to be stored in field 130M of server session data structure 
130 relating to the current close session process 411. The 
value of label -value pair 4817D isobtained from customer 
user 203's response to a prompt from customer application 
45 software 210 and is preferably limited to sixty characters to 
for convenience in display. If a record-note was created by 
customer user 203 during open session process 407, the 
value of label-value pair 4817D is added to the value 
previously stored in field 130M. 
50 Label-value pair 4817E has the label "session-id". The 
value associated with label-value pair 4817E is obtained 
from field 240A of customer session data structure 240 and 
is stored in field 256F. 

Label-value pair 4817F has the label "request-log". The 
55 value associated with label-value pair 4817F is either "yes" 
or "no". The value of label-value pair 4817F reflects whether 
t customer user 203 has elected to receive a log of the 
transactions at step 1802. The value of label-value pair 
4817F is stored in field 256G of customer pending data 
60 structure 250. 

Label-value pair 4817G has the label "key". The vahie of 
label-value pair 4817H represents a hash of the modulus part 
of the RSA public/private key pair of customer persona 
120.1. The value of label-value pair 4817G permits server 
65 computer 100 to confirm that the RSApublic key maintained 
in field 120B (FIG. 4B) is the same key used to sign message 
. CS1 (label-value pair 4817H). 
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Label-value pair 4817H has the label "signature". The The opaque section contents of message CS2 are shown 

value of label-value pair 48171 represents the digital signa- in FIG. 40B where label-value pair 4917A has the label 

hire of customer persona 120.1. For message CS1, the value "type". The value of label^vahie pair 4917A references a 

of label-value pair 4817H is a hash of label-value riairs record in message data structure 270 (FIG. 5A) which sets 
4813A-4813E and label-value pairs 4817A-4817G in 5 forth the labels of the opaque section contents of message 

alphabetical order, encrypted with the RSA private key of CS2. The value of label-value pair 4917Ais obtained from 

customer persona 120.1. The RSA private key of customer server software 110 

persona 1201 is obtained item field 220H. Label-value pair 4917B has the label "server-date" The 

^^I '^f ^h 15 ^™ mb A ed m accoida ?f value of label-value pair 4917B indicates the date and time 

with message assembly procedure 800. Message assembly m CS2 was assembled according to the clock of 

procedure 800 was previously described for message Rl iU ^^^^.^ inft 6 

with reference to FIG. 9. One noted exception: A copy of 75 computer 1W. • 

message CS1 is saved in field 256H. ^ Lab f val ] L f 1 917C . has me label "response-code". 

Referring again to FIG. 38, close session process 411 ^ value of labe l-value pair4917C mdicates whether close 

continues at step 1804. There, customer computer 200 session P rocess 411 was a success or failure, 
transmits message CS1 to server computer 100. Customer 15 Label-value pair 4917D has the label "swseverity" 

computer 200 waits for a reply message CS2 from server (software severity). The value of label-value pair 4917D 

compter 100. indicates whether customer application software 210 needs 

At step 1805, server computer 100 received message CS1 t0 ^ e updated, but is still usable ("warning") or is no longer 

from customer computer 200 and unwraps message CS1 by usable ("fatal"). The value of label-value pair 4917D is null 
executing server message unwrap procedure 900 for mes- 20 ^ customer application software 210 is current, 

sage CS1. Server message unwrap procedure 900 was pre- Label-value pair 4917E has the label "swmessage" 

viously described for message Rl with reference to FIG. U. : (software message). The value of, label-value pair 4917E 

A noted exception: a copy of message CS1 is stored in field indicates instructions as to what customer user 203 should 

140E - do in the case of a "fatal" or '"warning" software severity. 

At step 1806,. if any of the tests of steps 904, 909A, 912, ^ The value of label-value pair 4917E is only present if the 

914, 915 or 916 caused an error flag to be set at step "905, value of label-value pair 4917D is not null 

error processuig proadures are executed by server computer Label-value .pair 4917F has the label "message". The 

100 at step 1814. While the level ^of error processing at step value of label-value pair 4917F is a free texTmessage 

« e ™ orsuccess condition returned! 

a minim u m , failures of the signature, and form, and a fatal „ al „ a „■ amt^ j • j- i j* 

return on the software check procedure result in a return 30 J^ 1_Value P ™ 49170 and 15 ^P 1 ^ to US€r 

message containing a code that can be processed by cus- T * u i i ■ a M -~ t. iL , L , ttl * „ ^ ■ , 

tomer application software 210 and a message that can be , ^bel-value pair 4917G has the label "fee". The value of 

read by customer user 203. The error processing procedure Ia °el-value pair 4917G indicates a fee,, if any, charged to 

in step 1814 entails associating a flag with a specific error customer ^ 203 for processing message CS1. 

code (described in the context of the return message CS2 35 I^bel-value pair 4917H has the label "amount" and 

below) and creating a text message (either from a data indicates the amount of electronic funds remaining from the 

structure of messages or a message sent by the system amount allocated to the session during open session process 

administrator). Server computer 100 then generates a mes- 407 all payments and fees are deducted. If the process 

sage CS2 similar to that described below, to customer °f message CS1 is successful, the amount represented by 

computer 200 conveying the error code and any related 40 label-value pair 4917H will be added to cash container field 

message. 120G.2 (FIG. 4Q. 

If the tests of steps 904,909A, 912, 914, 915 and 916 did The assembly of message CS2 is now complete, 

not cause an error flag to be set at step 905, processing Referring again to FIG. 38, at step 1809A, message CS2 

continues at step 1807. There, server computer 100 invali- is sent (transmitted) from server computer 100 to customer 

dates (updates server data structures) the session identified 45 computer 200. 

in label-value pair 4817E by setting the status flag in field At step 1810, customer computer 200 receives message 

130Lto "closed". CS2 from server computer 100 and unwraps message CS2 

At step 1809, server software 110 assembles reply mes- by executing message unwrap procedure 1100. Message 

sage CS2, according to server message assembly procedure unwrap procedure 1100 for message CS2 was previously 

1000. Server message assembly procedure 1000 was preyi- so described for message R2 with reference to FIG. 14. 

ously described for message R2, with reference to FIG. 12. At step 1811, 

The content of message CS2 (FIGS. 40A and 40B) is now (1) if an error flag was set at step 1105, the flag will be 

described. detected at step 1811 and processing of message CS2 

Label-value pair 4913A has the label "id". The value of will terminate at step 1812. From the perspective of 

label-value pair 4913 A indicates the persona id for customer 55 customer user 203, no further action is taken with 

user 203. The value of label-value pair 4913A is obtained respect to message CS2. In the present invention, a 

from the value of label- value pair 4813A of message CS1. mechanism is provided within customer application 

Label-value pair 4913B has the label "transaction". The software 210 to create and send to server computer 100 

value of label-value pair 4913B is a transaction number. The a message. This message includes the. CS2 message as • 

value of label-value pair 4913B is the same as that received 60 received by customer computer 200 and any diagnosis 

in message CS1 in label-value pair 4813B. of what caused the message to fail. No response to this 

Label-value pair 4913C has the label "date". Label-value message is sent by server computer 100 to customer 

pair 4913C has the same value as label-value pair 4813C of computer 200. Rather, the information is used to ascer- 

message CS1. tain whether a problem exists within the system and if 

Label-value pair 4913D has the label "service-category". 65 appropriate corrective measures need to be taken. 

Label-value pair 4913D has the same value as label-value (2) if no error flag was set at step 1105 but an error in 

pair 4813E of message CS1. message CS1 was detected at step 905, processing will 
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continue at step 1813 where the content of label-value 
pair 4717C is checked. If the value of label-value pair 
, 4917C is other than "success", error processing rou- 
tines are performed at step 1815 causing customer 
application software 210 to display the message con- 
tained in label-value pair 4917F- associated with the 
content of label-value pair 4917C and to interpret the 
value of label-value pair 4917C and take whatever 
action may be associated with that value; or 

(3) if message CS1 passed the check at step 905 and no 
flags were set at step 1105, processing continues at step 
1816 where customer application software 210 updates 
customer data structure 202 as follows: 

The amount from label-value pair 4917H is added to field 
220L 
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A. Registration process 401 

Registration process 401 is identical for a customer and a 
merchant. Only the registration of customer user 203 is 
described below. 

Customer user 203 runs customer application software 
210 which prompts customer user 203 for its assent to one 
or more legal agreements. In response to a request for 
customer user 203's assent to a legal agreement, customer 
user 203 selects "agreed". Customer application software 
210 then prompts customer user 203 for the following 
information: a desired persona id, the email address of 
customer user 203, the desired language in which any error 
messages will be displayed, the autoclose passphrase to be 



Record 267 of customer log data structure 260 is updated 15 associated with the persona, and the default currency of the 



as follows: the persona id from label-vahie pair 4913A is 
stored in field 267H. The transaction number from label- 
value pair 4913B is stored in field 267B. The date from 
label-value pair 4917B is stored in field 267C. The response- 
code from label-value pair 49i7C is stored in field 267F. The 20 
software severity code from label-value pair 4917D is stored ' 
in field 267D. The software-message from label-value pair 
4917E is stored in field 267E. The response message asso- 
ciated with the response code from label- value pair 4917F is 
stored in field 267G. The fee from label- value pair 4917G is 25 
stored in field 267K. The amount from label-value pair 
4917H is stored in field 2671. , 

If the value of request-log label-value pair 4817F in 
message CS1 was set to "yes", a report will be delivered to 



persona. 

In response to a prompt for a desired persona id, customer 
user 203 selects "brianb". In response to a prompt for an the 
email address, customer user 203 enters ' 
"brianb@reahty.com". In response to a prompt for the 
desired language for error messages, customer user 203 
selects "English". In response to a prompt for the autoclose 
passphrase associated with the persona, customer user 203 
enters "badnews". In response to a prompt for the default 
currency of the persona, customer selects "U.S. dollars". 

Customer user 203 is prompted to enter a password. 
Customer user 203 then enters "enterprise". Customer user 
203 is prompted to re-enter the password and complies. 



customer computer 200 of all transactions initiated by 30 Customer application software 210 then generates a RSA 

customer user 203 during the session just closed. public/private key pair and initiates the creation of message 

Processing continues at step 1817 where close session Rl as previously described, which message will include the 

process 411 ends, following: 



transaction-number 


2277052 


date: 


i9951105100505456 


serverkey: 


CC1001 


type: 


registration 


service-category: 


admin 


opaque: 




server-date: 


19951105100506656 


swvcrsion: 


l.Owin 


content-language: 


en-us 


default-currency : 


usd 


requested-id: 


BrianB 


email: 


brianb@reality.com 


agreements: 


75 


atttocJose-passphrase : 


badnews 


pubfcey: 


aslfflasdflaqylfdjslyafkj§slalg^ 




■ flasflasjylqljslalgfjuyresd^ 
n75cxzl 


signature: 


sdjflsajfflcsjdllcrjl^ 




kfljydjIfa.sdlnpryhi«7Twi mV ] nlm rm TihvgytfrdXBZflqWfl 3r5 t6 




y7u8io09km+ 



V. Sample Transaction " 

Below is a description of a sample transaction. In the 
sample transaction, customer user 203 and merchant user 
303 each perform registration process 401, instrument bind- 
ing process 403 ; load/unload process 405, open session 
process 407, transaction payment process 409* and close 
session process 411. By performing these processes, cus- 
tomer user 203 is able to purchase a pair of "rocket shoes" 
from Acme Products. 

It should be noted that in the current invention, message 
label-value pairs for which no value have been assigned are 
preferably not included in a transmitted message. This 
attribute of the current invention is reflected in the sample 
messages depicted below. 



Server computer 100 creates a new record 140.1 in server 
message log 140 and saves a copy of message Rl in field 
140E. Server computer 100 then unwraps message Rl and 
processes it as previously described and updates record 
140.1 of server message log 140 as 
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•persona-id: 


brianb-23 


session-id 




tranaction-numben 


2277052 


index: 




incoming-message : 


copy of message Rl " 


response-message: 





81 



5,870,473 



Server computer 100 then compares the id requested by 
customer user 203 to the list of existing personas. If the 
requested persona id is unique, it creates a persona record 
120.1 for customer user 203 as follows: 



82 



user 203 then enters "Brian Brian, 100 Elm Street, Nice 
Place, Va. 00000 U.S.A.". 

Customer user 203 selects "bank account" and is 
prompted for the following information: bank account num- 



persona-id: 

email: 

public-key: 

date-registered: 
content-language: 
autoclose-passphrase : 
cash-container-data: 
agreements: 

instrumen t-binding-data: 



brianb-23 

brianb@reality.com 

asipasdfi^jjtfdjslyaflgrjd^ 

sjy]q"fjsla]gijuyresdfut]q»iuqw 

19951105100507556 

en-us 

badnews 



*" Server computer 100 then assembles message R2, saves a 
copy of it in field 140F of record 140.1 of server message log 
data structure 140j and transmits message R2 to customer 
computer 200. Message R2 contains the following: 



ber; whether the bank account is the autoclose account for 
the persona; a description of the account; and customer user 
203's assent to one more legal agreement. Customer user 
203 is prompted to change any information" necessary to 



transaction: 

date: 

type: 

service-category: 

opaque: 

server-date: 
requested-id: 
response-id: 
email: 

response<ode: 
publcey: 



swseverity: 
swmessage; 



2277052 

19951105100505456 
registration-response 
admin 

19951105100507556 

brianb 

brianb-23 

brianli@realUy.com 



aslf] flasdflasjy lfiijslyaflg rjslakjryldskajynTcajsyldrj lasifesltj 

fiasdflasjykjijslalqrjuyresetf^ 

n75cxzl . 

warning 

New software is available. 



Customer computer 200 unwraps and processes message 
R2 as previously described. Customer, application software 
210 creates a record of persona "brianb-23" in customer 
persona data structure 220 as follows: 



describe the name, address, and telephone number of the 
holder of the instrument. 

40 

In response to a prompt for a the bank account number, 
customer user 203 enter "059013218175654". In response to 



persona-id: 

email: 

public-ley: 



date-registered: 
content-language: 
autoclose-passphrase : 
cash-container-data : 
agreements: 

instrument-binding data: 

software-options: 

private-key: 



brianb-23 

. brianb@reality.com 

aslrjflasdflasjylfdjalyaflcj fjslaJqfyld&kaj yfOcajsyldfjlasifaslfj 

flasdnasjykjfjslalqrjuyresdr^ 

n75cxzl 

19951105100507556 

en-us 

badnews 



75 



default 

~difaihbrfvedc3erf^6yu87yg0oki^ 
j7yfgdcsdiv6y89i0oolujmlmcv^^ 
6tg7yhlghg£2waaz4ed5tgfv 



B. Instrument Binding Process 403 

Instrument binding process 403 is the same for both 
customers and merchants. Only the binding of ah instrument 
by customer user 203 will be described. 

Bind instrument process 403 begins when customer user 
203 selects the bind instrument operation from the client 
application. Customer application software 210 prompts 
customer user 203 for a default name and address. Customer 



a prompt to the response for whether the account, "is the 
60 autoclose account for the persona, customer user 203 enters 
"yes". In response to a prompt to change the displayed name, 
address, and telephone number, customer user 203 declines. 

"In response to a prompt for a description of the account, 
customer user 203 enters "My fun account". In response to 
a prompt for customer user 203 's assent to a legal 
agreement, customer selects "agreed". Customer user 203 is 
prompted to "bind instrument" with server computer .100. 
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This act causes customer application software 210 to create 
a message BU as previously described, which message will 
include the following: 



id: 


brianb-23 


transaction-number: 


2277053 


date: 


19951125100510589 


serverkey: 


CO 001 


service-category: 


admin 


opaque: 




type: 


bind-instrument 


servex-date: 


19951125100512689 


swversion: 


• l.Owin 


instrument- numb er; 


059013218175654 


instrument- type: 


dda 


instrument-category: 


dda . 


instrument- functions : 


bad, unload 


instrument- salt: 


4bnm8poetqv« 


instrument- name : 


Brian Q. Brian 


instrument- street: 


100 Elm Street 


instrument-city: 


Nice Place 


instrument-state: 


VA 


instrument-postal-code: 


0000 


instrument- country : 


USA 


agreements: 


75,123 


auto close: 


yes 


auto dose-p assp hrase : 


badnews - 


key: 


4/Rocs+2ac8« 


signature: 


sjadllasrzfelksajzlfrzlksajzu^^ 
ajzl 

rrzlisajzlrjszlfjsldfj lakflsa|£sa/9iu7hgfce/juy+poiuh 
nbvcdewqazxp 



Server computer creates a new record 140.2 in server 
message log 140 and saves a copy of message BI1 in field 
140E. Server computer 100 then unwraps message BI1 and 
processes it as previously described and updates record 
140.2 of server message log 140 as follows: 



-continued 



persona-id: 


brainb-23 


session-id 




transaction-number: 


2277053 


index: 




incoming-message : 


copy of BD 


response-message : 





Server computer 100 then updates server persona data 
structure 120.1 for persona "brianb-23" by entering "bad- 
news" into the autoclose passphrase field 120F and ' by 
adding instrument binding data to field 120H as follows: 



persona-id: 
instrument-type: 
Ins trument- number : 
Instrument-native currency 
Instrument-prefix: 
Le^al- agreements: 
Instrument-hash: 
Issuer-identification number: 
Ins trument- bolder-name: 
Iiistrument-holder-address : 
Instrument-bind-date: 
Instrument- first-used-date : 
Binding-status:' ' 
Sale-transaction-eaabled : 
Sale-transaction-limit: 
Credit-transaction-enabled: 
Credit-transaction-limit: 
Load-cash-enabled: 
Load-cash-transaction limit: . 
Unload-cash-enabled: 



brianb-23 
dda 

aswerfevg [encrypted] 
usd 

055654 
75, 123 

uou980y57rd98jnhgt54e3— 
735980 

lkpipoipoi [encrytped] 
oipipoipipo [encrypted] 
19951125100513583 

created 
no 

no 

yes 

usd 1000.00 
yes 



Unload-cash-transaction limitT -\ 
Autoclose- binding: yes 
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Server computer 100 then assembles message BI4, saves 
a copy of it in field 140F of record 1402 of server message 
log 140, and sends message BI4 to customer' user 203. 
40 Message BI4 contains the following: 



persona-id: 

transaction-number: 

date: 

45 service-category: 
opaque: 

type: 

server-date: 
response-code: 
sWBeverity: 
swmessage; 
instrument-number 
instrument-type: 
instrument-issuer 
instrument-issuer-country: 
instrument-functions: 
instrument-number 
instrument-type: 
instrument-issuer 
instrument-issuer-country: 
instrument-rUnctions : 
instrument-salt: 



brianb-23 
2277053 

.19951125100510589 
admin 

bind-instrument- response 

19951125100513583 

success 

warning 

New software is available. 

059013218175654 

dda 

East Bank of the Mississippi 
us 

-load, unload 

059013218175654 

dda 

East Bank of the Mississippi 
us * 

load, unload 
4bnm8poetqv- 



Customer computer 200 unwraps message BI4 and pro- 
cesses it as previously described, then updates record 220.1 
in customer persona data structure 220 for persona "brianb- 
65 23" by adding instrument binding data to field 220J as 
follows: 
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persona-id 


brianb-23 


tastrumcnt-numbcn 


059013218175654 


instrument-description : 


my fun account 


holder-name: 


Brian Brian 


holder-address: 


100 Elm Street 


holder-city: 


Nice Place, VA 


holder-country: 


. USA 


holder-postal-code : 


ooooo 


holder-country-code : 


1 . 


holder-area-code: 


.703 


holder- telephone: 


555-1212 


currency: 


usd 


transact-s ale-flag: 


no 


transact-credit-fiag: 


no 


unload- funds -flag : 


yes 


load-funds-flag: 


yes 


status: 


- approved 


mstrument-recurring-data : 


instrument-number 05901321 81 75654jins trument- 




t ype:ddajinstrumc at- issue riEaatBanto fit c 




J^sissippiJimLrumem-issuer-cou^ 




functions : load,unIoac^instrument-salt:4bhin8poetqv-» 


agreements: 


75,123 



C Load/unload Process 405 

Load/unload process 405 begins when customer user 203 
selects the load operation from customer application soft- 25 
ware 210. Customer application software 210 then prompts 
customer user 203 for the instrument from which to load 
funds to persona brianb-23. Customer user 203 selects "my 
fun account" and is prompted for the amount to be trans- 
ferred. In response to a prompt for the amount, customer 30 
user 203 enters $100.00. Customer application software 210 
then assembles message LU1 as previously described and 
sends it to server computer 100. Message LU1 contains the 
following information: 



Currency: usd 

Available-balance: 100.00 

On- hold-balance: O.OO 

Agency-account-number: 11 33 17834 



Server computer 100 then assembles message LU2, saves 
a copy of it in field 140E of record 140.3 of server message 
log 140, and transmits message LU2 to customer computer 
100. Message LU2 contains the following information: 



id: 


brianb-23 


transaction-number: 


2277054 


date: 


19951105103517688 


serveritey: 


CC1001 


service-category: 


cash 


opaque: 




type: 


load-unload-funds 


server-date: 


19951105103519788 


amount: 


usd 100.00 


key: 


4/Roos+2ac8= 


signature: 


Ujwlijwlmceiwlcerjdwewleiiawlrc 




cetjoWwleicjwtierqicJicKlqhoiweJiq^ 




qwer7y6t^juilco09p+po9ijht5re3wi 



Server computer creates a new record 140.3 in server 
message log 140 and saves a copy of message LU1 in field 
140E. Server computer 100 then unwraps message LU1 and 
processes it as previously described and updates record 
140.3 of server message log 140 as follows: 



persona-id: 


brainb-23 


session-id: 




transaction-number: 


2277054 


- index:. 




incoming-message : 


copy of LU1 


response-message: 





Server computer 100 then updates customer persona 
record 120.1 by adding cash container data to field 120G as 
follows: 
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.id: 


brianb-23 


transaction-number: 


2277054 


date: 


19951105103517688 


service-category: 


cash 


opaque: 




- type: 


load-unload-response 


server-date: 


19951105103607914 


amount: 


usd 100.00 


response-code: 
message; * 


success 


funds-loaded 


t swseverity: 


warning 


swmessage: 


New software is available. 


fee: 


. usd 0.0 


balance: 


usd 100.00 


session-hinds: 


usd 0.00 


on-hold: 


usd 0.00 • 
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Customer computer 200 unwraps message LU2 and pro- 
cesses it as previously described, then updates record 220.1 



5,870,473 
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in customer persona data structure 220 for persona "brianb- 
23" by entering "usd 100" into cash container field 220J. 
D. Open Session Process 407 

Create session process 407 begins when' customer user 
203 selects the open session operation from customer appli- 
cation software 210. Customer application software 203 
then prompts customer user 203 for the following informa- 
tion: desired session lifetime in minutes; maximum number 
of transactions to be conducted during session; the amount 
of funds to be available during the; session; and a memo 
describing the session. 

In response to a prompt for the desired lifetime of the 
session in minutes, customer user 203 enters "120".. In 
response to a prompt for the maximum number of transac- 
tion to be conducted during the session, customer user 203 
enters "25". In response to the prompt for the amount of 
funds to be available during the session, customer enters 
"70.00". In response to a prompt for a memo describing the . 
session, customer user 203 enters "Christmas shopping 
spree." 

Customer 200 then assembles a message OS1 and sends 20 
it to server computer 100. Message OS1 includes the fol-. 
lowing information: 
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^continued 



Persona- ID: 

Status: 

Memo: 

Transaction-data: 



brainb-23 
open 

Christmas shopping spree 



Server computer 100 also updates record 120.1 in server 
persona data structure 120 associated with persona "brianb- 
23" by deducting the amount "70.00" from the amount 
"100.00" from the available balance field 120G.2 of the cash 
container previously described. Server computer assembles 
a message OS2, saves a copy of it in field 140F of record 
140.4, and transmits message OS2 to customer computer 
200. Message OS2 includes the following information: 



id: 

transaction: 
date: 

service-category: 
opaque: 

type: 



brianb-23 
2277055 

19951105104131914 
cash 

open-session-response 



id: 


brianb-23 


transaction-number: 


2277055 


date: 


19951105104131914 


serverkey: 


CC1001 


service-category: 


cash 


opaque: 


open-session 


type: 


server-date: 


19951105104134014 


swversion: 


l.Owin 


record-note: 


Christmas shopping spree 


amount: 


usd 70.00 


key-lifetime: 


0120 ' 


key-uselimit: 


25 


key: 


4/Roos+2ac8- 


signature: 


knsdjBasjdzlMioi5793S4ng09kdfg)09eUTtna^nb909iJ 




ktujwjsi86tjf9086ptjf^r6jk46^d^ 




hgtr432zxcvbhgrcwql2rg8mko01 
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Server computer creates a new record 140.4 in server 
message log 140 and saves a copy of message OS1 in field 
140E. Server computer 100 then unwraps message OS1, 
processes it as previously described, and updates record 
140.4 of server message log 140 as follows: 45 



persona-id: ■ 


brainb-23 


session-id: 




transaction-number: 


2277055 


index: 




incoming-message: 


copy of OS1 


response-message: 
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Server computer 100 then creates a record 130.1 in server 
session data structure 130 associated with persona id 55 
"brianb-23". Record 130.1 contains the following 



-continued 



server-date: 

response-code: 

swseveriry; 

swmessage; 

key-lifetime: 

key-uselimit: 

amount: 

foreign-exchange: 

session- funds: 

balance: 

on- hold: 

fee: 

session-id: . 
session-key: 
session- salt: 



19951105104137179 



warning 

New software is available. 

0060 

15 

usd 70.00 

cad 0.60 gbp 1.55 

usd 70.00 

usd 30.00 

usd 0.00 

usd 0.00 

J/Pi+sqGtgH- 

7ujm8iktgTRxfv3edc9olk-^ 

aa5yh8fdkl+- 



Session-Q): 

Session-Key: 

Session-Salt: 

Currency: 

Opening-Amount: 

Current-Amount 

Opening-Date: 

dosing- Date: 

Key-Use-limit: 

Key-lifetime: 



J/Pi+sqGtgH- 
7ujm8fktgTRrfv3edc9olk« 
aa5yh8fdkl+- 
usd 
70.00 
• 70.00 
1995110510137179 

15 

0060 
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Customer computer 200 unwraps message OS2 and pro- 
cesses it as previously described, then creates a new record 
2401 in customer session data structure 240 associated with 
persona "brianb-23" as follows: 
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Session- ED: 

Session-Key: 

Session-Salt: 

Currency: 

Opening-Amount: 



J/Pi+sqGtgH- 

7ujm8iktgTRrfv3edc9oIk« 

aa5yh8fdkl+- 

usd 

70.00, 
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-continued 



Current-Amount 


70.00 


Opening-Date: 


19951105104137179 


Key Use-limit: 


15 


Key^lifetime: 


0060 


Memo: 


Christmas shopping spree 



The process whereby merchant user 303 opens a session 
is the same except that a merchant will not transfer funds 
from its persona cash container to a session register. This is 
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E. Transaction Payment Process 409 

Transaction payment process 409 begins when customer 
user 203 responds to an offer from merchant user 303 to sell 
rocket shoes under, specified terms by selecting "cash pay- 
ment" as the mechanism for payment. This act causes 
merchant computer 300 to assemble message PR1 and 
transmit it to customer computer 200 as previously 
described. Message PR1 includes the following information: 



type: 

merchant-cdd: . 

mcrchant-order-id: 

merchant-date: 

merchant-swversion: 

note; 



merchant-amount: 
merchant-amount2 : 
accepts: 
uri-pay-to: 
uri -cancel: 

url-success: 
url-fail: 

merchant-signed- hash- key: 
merchant-signed- hash: 



payment-request 
Acme-12 

1231-3424-234242 

19951105104536378 

foo69 *' 

ACME Products 

Purchase of 1 pair "Rocket Shoes" at $37.50 ea. 
Shipping and handling $5.00 
Total Price: $4250 
Ship to: 

Brian Brian 
^ 100 Elm Street 
Nice Place, VA 00000 USA 

usd 42.50 
cad 54.25 

visa; master, amex; JCPenny; macy 
httpyAvw^ACMEcom/ServerPayrricnt 
ht^^/wn^ACMEcmn/GybcrPayment 
Cancel 

hffp V/wwwACMELcom/o rdersuccess 

http y/www ACME.com/orderf ail 

lSL2s/vFQ0BXfU98LZNTWhQ— 

Jdrjlkdfgflcdrsu&dtjgl^ 

6jCS985kr^S6^894j6g-ri)94543jvndmlma2cipl 



because a merchant expects to receive funds and does not 
need funds available to it during a selling session. Server 
computer 100 creates a record 1302 in server session data 
structure 130 associated with merchant user 303* s persona 
"acme-12" as follows: 40 



session- ID: 


k/iLrHpPmHg- 


session-key: 


3ejkPOM7T+poBQW9ipqwZS=» 


session-salt: 


qw891k3vA2~~ 


currency: 


usd 


opening-amount: 


0.00 


current-amount: 


0.00 


opening-date: 


110595063012147 


closing-date: 




key-use- limit: 


090 


'key-lifetime: 


0960 


persona-ID: 


acme-12 


status: 


open 


memo: 


shoe department sales 


transaction-data: 





Upon opening a session, merchant computer 303 creates 
a new record 370.1 in merchant cash log data structure 370 
as follows: 



' type: -open-session " ^ 

status: open 

transaction- number: - 55443322 

requested-session-duration: 0960 

requested-session-count: 90 

session-id: k/iL+tpPmHg« 

result-code: success " 6*5 



Merchant computer 300 also creates a new record 350.1 
of merchant amount data structure 350 as follows: 



order-id: ' 1231-3424-234242 
amount-of-transaction: usd 42.50 

flag: . • pending 



Customer computer 200 processes message PR1 as pre- 
viously described. In response to a prompt from customer 
application software 210, customer user 203 indicates its 
acceptance of the offer of merchant user 203 by selecting 
"pay cash". This act causes customer computer 200 to 
assemble message CA1 and transmit it to merchant com- 
puter 300. Message CA1 includes the following informa- 
tion: 



. type- 


cash-payment 


version: 


1 


session- id: 


J/Pi+sqGtgH- 


index: 


1 


payee-currency: 


usd 


note- hash: 


tyriokljhgbvxczm7rfde4— 


payee-id: 


acme-12 


order-id: 


1231-3424-234242 


service-category: 


cash 


opaque: 




amount: 


usd 4250 


auth-code: 


iou23 4rfgvbmaqH-poliu7=» 



Merchant computer 300 processes message CA1 as pre- 
viously described. Merchant computer 100 then assembles 
message CA2 as previously described and transmits it to 
server computer 100. Message CA2 includes the following 
information: 
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version: 

session-id: 

index: 

service-category: 
merchant- opaque: 

type: 

version: 

subversion,,: 

payer-scssion-id,,: 

payer-indeXj,: 

note-hash,,: 

payee-id,,: 

order-id^: 

merchant-amount,,: 
auth-code: 
customer-opaque: 



1 

k/iL+tpPmHg- " 

77 

cash 

cash-collection 
1 

Cash-payment 
1 

J/Pi+sqGtgH- 
1 

kchiiZSWAUlpklMogwuQ— 
Acme- 12 

- 1231-3424-234242 
usd 4250 

UjkHgtK/38uhzxs9io3+PL— 

jT^fditdflq'gdfiit029jr5q0875jCSjmgmbnfmrt 

kjrjghnvm£ha2apla]ffidjjdfhjgutiroklop8tre'wqasz 



Merchant computer 300 updates record 370. 1 of merchant 
cash log data structure 370 by adding the following addi- 
tional data to the existing record (all of record 370.1 is 
shown for clarity): 



type: 


cash payment 


status: 


pending 


order-id: 


1231-3424-234242 


customer-session- ID: 


J/Pi+sqGtgH- 


customer-Lndcx-numbcr: 


1 


customer-currency : 


usd 


merchant-session-ID: 


k/iL+tpPmHg- 


me re hint-index -number: 


77 - 


merchant-currency: 


usd 


merchant-arnount-requested : 


4250 


amount-credited: 


4250 


fees-paid: 


0.00 


type: 


open-session 


status: 


open 


transaction-cumber: 


. 78765437 


requested-fiesfiion-duration: .. 


0960 


requested-sessios-count 


90 


session-ID: 


k/iL+tpPmHg- 


result-code 


. success 
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Server computer creates a new record 140.5 in server 
message log 140 and saves a copy of message CA2 in field 
140E. Server computer 100 then unwraps message CA2, 
processes it as previously described. Server computer 100 45 
checks records 130.1 and 1302 of server session, data 
structure 130 to determine if both persona brianb-23 and 
persona acme- 12 have open sessions. If a session is invalid, 
server computer terminates transaction payment process 
409. Here, server computer 100 proceeds and updates record 50 
140.5 of server message log 140 as follows: 



persona-id: 


acme- 12 


session-id: 


k/LUtpPmHg- 


transactio n- number: 




index: 


77 


incoming-message : 


copy of message CA2 


response-message 
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Server computer also updates record 130.1 of server 
session data structure 130 by associating the" following 
information with transaction data field 130N: 



amount: usd 42.50 €5 

customer-session-id: J/Pi+sqGtgH- 



-continued 



merchant-order-id: 1231-3424-234242 
merchant-peisona-id: acme- 12 

customer-index: 1 



Server computer also updates record 1302 of server 
session data structure 130 by associating the following 
information with transaction data field 130NN: 



-amount: 


usd 4250 


customer-session-id: 


J/Pi+sqGtgH- 


merchant-order-id: 


1231-3424-234242 


merchast-peisona-id: 


acme-12 


merchant-index: 


77 



Server computer 100 then assembles message CA3 and 
transmits it to merchant computer 300 as previously 
described. Message CA3 includes the following informa- 
tion: 



type: 


from-server 


version: 


1 • 


session-id: 


k/iL+tpPmHg- 


index: 


77 


service-category: 


cash 


merchant-opaque : 




subtype: 


cash-batch-receipt 


subversion: 


1 


request-version: 


1 


response-code: 


success 


fee: 


usd 0.00 


subtype,,: 


cash-payment-receipt 


subversion,,: 


1 


payer-session-tdjj : 


J/Pi+sqGtgH= 


payer- index,,: 


1 


response-coden: 


success 


. collected- am ount^: 


• usd 4250 


order-id: 


1231-3424-234242 : 


auth-code: 


pl2P+/BNfr59dsXz+lmnTP=- 


customer-opaque: 




service-category: . 


. cash 


response-code: 


success 


amount: 


usd 4250 


order-id: - 


1231-3424-234242 


auth-code: 


]qTUY7f72T+pGB65RXE+ho-» 



Merchant computer 300 unwraps message CA3 and pro- 
cesses it as previously described. Merchant computer 300 
updates record .350.1 of merchant amount data structures 
350 by setting flag field 350C to "paid". 

Merchant computer 300 updates record 370.1 of merchant 
cash log data structure 370 as follows: 
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Status field 370B is set to "success". Amount credited 
field 370k is set to "usd 42.50". 

Merchant computer assembles message CA4 and trans- 
mits it to customer computer 200. Message GA4 includes the 
, following information: . 5 



type: 


cash-payer-receipt 


version: 


1 


session-id: 


k/iL+tpPmHg- 


service-category: 


cash 


index: • 


77 


order-id: 


1231-3424-234242 


opaque: 




response-code: 


success 


amount: 


usd 4250 


order-id: 


1231-3424-234242 


auth-codc: 


mhgD4QaBPkj+ vWlg HytR5J=» 
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Customer computer 200 unwraps and processes message 
CA4 as previously described. Customer, computer 200 
updates record 240.1 of customer session data structure 240 20 
by deducting "$42.50" from current amount field 240F 
leaving a balance of $27.50. 

F. Close Session Process 411 

Close session process 411 begins when customer user 203 
chooses the close session prompt from the display on 25 
customer computer 200. This act causes customer computer 
200 to assemble message CS1 and transmit it to server 
computer 100 as previously described. Message CS1 ' 
includes the following information: 
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Server computer assembles a message CS2, saves a copy 
of it in field 140F of recored 140.6, and transmits message 
. CS2 to customer computer 200. Message CS2 includes the 
following information: 



id: 


brianb-23 


transaction: 


2277057 


date: 


19951105110223666 


service-category: 


cash 


opaque: 




type: 


close-session-response 


server-date: 


19951105110301999 


response-code :- 


success 


swseverity: 


warning 


swmessage; 


New software is available. 


fee: 


usd 0.00 


amount: 


usd 27.50 



Customer computer 200 unwraps and processes message 
CS2 as previously described. Customer computer 200 
updates field 2201 of record 220.1 of customer persona data 
structure 220 by adding $27.50 to the current value of field 
2201 ($30.00) for a balance of $57.50. Customer computer 
200 deletes record 240.1 of customer session data structure 
240. 

While the foregoing description of the present invention 
has been given as an example, it will be appreciated by those 
of ordinary skill in the art that various modifications, alter- 
nate configurations and equivalents may be used without 
departing from the spirit and scope of the present invention 1" 
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Server computer creates a new record 140.6 in server 
message log 140 and saves a copy of message CS1 in field 
140E. Server computer 100 then unwraps message CS1, 
processes it as previously described, and updates record 
140.6 as follows: 



persona id- 


brainb-23 


session id: 




transaction: 


2277057 


index: 




incoming-message: 


copy of CS1 


response-message: 





Server computer 100 then updates record 130.1 in server 60 
session data structure 130 associated with persona id 
. "brianb-23" by adding the value in current amount field 
130F ($27.50) to the amount in the available balance field 
120G.2 of the cash container previously described for a 
balance of $57.50, by entering the value 65 
"19951105110301999" into closing date field 130H, and by 
changing status field 130L from "open" to "closed" and. 



We claim: 

1. A method for securely communicating in a communi- 
cation system, wherein the communication system com- 
prises a first device at a first party's location, a second device 
at a second party's location, and a server in communication 
therewith, wherein the method comprises: 

(a) creating a first session associated with the first party, 
wherein said first session has first use parameters for 
limiting the duration that said first session can be used 
and a first set of data,- wherein said first use parameters 
and said first set of data are identifiable by the server; 

(b) creating a second session associated with the second 
party, wherein said second session has second use 
parameters for limiting the duration that said second 
session can be used and a second set of data, wherein 
said second use parameters and said second set of data 
are identifiable by the server; and 

(c) linking a portion of said first session with a portion of 
said second session in the communication system, 
wherein said portion of said first session includes said 
first set of data and said first use parameters and said 
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portion of said second session includes said second set 
of data and said second use parameters; 

(d) verifying the first and second parties based upon at 
least portions of said first and second sets of data by the 
server; and 

(e) deterrnining whether said first and second sessions can 
be used based upon said first and second use parameters 
by the server 

. so that when the server verifies the first and second 
parties and determines that said first and second 
sessions can be used, the first and second parties are 
assured of communicating securely in the commu- 
nication system. 

2. The method of claim 1 wherein certain of said first set 
of data is not transmitted between \the first device and the 
server after said first session is created and certain of said 
second set of data is not transmitted between the second 
device and the server after said second session is created. 

3. The method of claim 2 wherein said first and second 
sets of data include first and second keys, respectively, and 
wherein the server verifies the first and second parties using 
said first and second keys. 

4. The method of claim 1 wherein said first use parameters 
are determined by the first party and said second use 
parameters are determined by the second party. 

5. The method of claim 1 wherein said first and second use 
parameters are determined by the server. 

6. The method of claim 1 wherein said amount of elec- 
tronic funds have (a) an amount of electronic funds available 
to the first party for the duration of said first session, (b) a 
length of time ' that said first session will last and (c) a 
number of transactions that the first party may perform 
during said first session. 

7. The method of claim 1 wherein said second use 
parameters comprise (a) a length of time that said second 
session will last and (b) a number of transactions that the 
second party may perform during said second session. 

8. A method for securely communicating in a communi- 
cation system, wherein the communication system has a 
device at a user's location and a server in corrimunication 

^ therewith, wherein the method comprises: 

a. transmitting a request from the device to the server for 
creating a session having use parameters associated 
therewith; 

b. encrypting a first key with a second key by the server; 

c. transmitting said encrypted first key and said use 
parameters associated with said session from the server 
to the device; 

d. receiving said encrypted first key and said use param- 
eters by the device and decrypting said encrypted first 
key so that the device can communicate securely in the 
communication system by using said decrypted first 
key according to said use parameters. 

9. The method of claim 8, wherein said first key is a DES 
key. 

10. The method of claim 9, wherein said second key is a 
DES key. 

U. The method of claim 8, wherein said secure commu- 
nication is at a security level greater than DES. 

12. the method of claim 8, further comprising a second 
device at a second user's location wherein said second 
device is also in communication with the user's device and 
the server and wherein the method farther comprises: 
a. transmitting a second request from the second device to 
the server for creating a second session having second 
use parameters associated therewith; 
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b. encrypting a third key with a fourth key by the server; 

c. transrm^ting said encrypted third key and said second 
use parameters from the server to the second device; 

d. receiving said encrypted third key and said second use 
parameters by the second device and decrypting said 
third key so that the second device can communicate 
securely in the communication system by using said 
decrypted third key according to said second use 
parameters. 

13. The method of claim 12, wherein said third key is a 
DES key. 

14. The method of claim 12, wherein said fourth key is a 
DES key. . 

15. The method of claim 12, wherein said secure com- 
munication is at a security level greater than DES. 

16. The method of claim 12, further comprising: 

a. transmitting a first set of data from the user's device to 
the second device, wherein said first se t of data includes 
an encrypted portion and an unencrypted portion, . 
wherein said encrypted portion is encrypted using said 
decrypted first key and at least a portion of said 

, unencrypted portion of said first set of data; 

b. receiving said first set of data by the second device and 
transmitting a second set of data together with said 
encrypted portion of said first set of data from the 
second device to the server, wherein said second set of 
data includes an encrypted portion and an unencrypted 
portion, wherein said encrypted portion of said second 
set of data includes at least a portion of said unen- 
crypted portion of said first set of data, and wherein 
said encrypted portion of said second set of data is 
encrypted using said decrypted third key and at least a 
portion of said unencrypted portion of said second set 
of data; and 

c. receiving said second set of data transmitted from said 
second device by the server and decrypting said- 
encrypted portion of said second set of data using said 
third key and said portion of said unencrypted portion 
of said second set of data so that said portion of said 
first set of data included in said encrypted portion of 
said second set of data is decrypted, and decrypting said 
encryp ted portion of said first set of data using said first 
key and said portion of said decrypted portion of said 
first set of data, 

so that the user is verified by the server using said first key 
and the second user is verified by the server using said third 
key. 

17. An electronic transfer system in a communication 
network for processing a transaction between a customer 
having a customer device, a merchant having a merchant 
device, and a server connected therewith, wherein the trans- 
action has terms associated therewith and wherein the server 
transfers electronic funds from the customer to the merchant, 
so that the merchant can provide a product to the customer, 
wherein the electronic transfer system comprises: 

a. the merchant device for 

(1) obtaining a first session from the server, 

(2) transmitting an invoice including at least a portion 
of the terms of the transaction, to the customer . 
device, 

(3) receiving a customer response to said invoice from 
the customer device and frararnitting a first set of 
data representing the transaction to the server, 
wherein said first set of data includes at least a 
portion of said customer response, 

(4) receiving a second set of data from the server 
indicating whether the transaction has been approved 



5,870,473 



97 



98 



by the server, wherein said second set of data 
includes a merchant part and a customer part, 
wherein said merchant part and said customer part of 
said second set of data include at least a portion of 
said first set of data; and 
(5) transmitting said customer part of said second set of 
data to the customer device; 
b. the customer device for 

(1) obtaining a second session from the server, 

(2) receiving said invoice including said portion of the 
terms of the transaction from said merchant device 
and transmitting said portion of said customer 
response to the merchant device, and 

(3) receiving said customer part of said second set of 
data from the merchant device; 

. c. the server having a merchant persona and customer 
persona stored therein, wherein said merchant persona 
represents the merchant and said customer persona 
represents the customer, wherein said merchant per- 
sona has a merchant electronic funds storage structure 
associated therewith for storing' electronic funds 
received by the merchant and said customer persona 
has a customer electronic funds storage structure asso- 
ciated therewith for storing electronic funds of the 
customer, wherein the server is for L 

(1) providing said first session to said merchant device 
and said second session to said customer device, 

(2) receiving said first set of data representing the 
transaction from the merchant device and processing 
said first set of data to determine whether the trans- 

. action has been approved, 

(3) transferring electronic funds from said customer 
electronic funds storage structure to said merchant 
electronic funds storage structure if the transaction 
has been approved, and 

(4) transmitting said second set of data to the merchant 
device indicating whether the transaction has been 
approved 

so that if the transaction has been approved, the merchant 
can provide the product to the customer 

18. The electronic transfer system of claim 17, wherein 
the merchant device further comprises communicating with 

. the server to bind a first financial instrument to said mer- 
chant persona; and 
wherein the customer device further comprises commu- 
nicating with the server to bind a second financial 
instrument to said customer persona. 

19. The electronic transfer system of claim 18, wherein 
the customer device further comprises transmitting a request 
to Uae server to transfer funds from said second financial 
instrument to said customer electronic funds storage struc- 
ture; and 

wherein the server further comprises receiving and pro- 
cessing said request to transfer funds and for transfer- 
ring funds from said second financial instrument to said 
customer electronic funds storage structure. 

20. The electronic transfer system of claim 19, wherein 
the customer device includes a customer session container 
for storing electronic funds of the customer during said 
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second session, and further comprises transmitting a second 
request to the server -for trarisferring electronic funds from 
said customer electronic funds storage structure to said 
customer session container; and 
wherein the server further comprises processing said 
second request and transferring the electronic funds 
from said customer electronic funds storage structure to 
said customer session container. 

21. The electronic transfer system of claim 20, wherein, 
the use of said first session is limited by first use parameters 
comprising (a) a length of time that said first session may 
last and (b) a number of transactions that the merchant may 
perform during said first session; and 

wherein the use of said second session is limited by 
second use parameters comprising (a) an amount of 
electronic cash available to the customer during said 
second session, (b) a length of time that said second 
session may last and (c) a number of transactions that 
the customer may perform during said second session. 

22. The electronic transfer system of claim 21, wherein 
the merchant device further comprises transmitting a third 
request for trarisferring electronic funds from said merchant 
session container to said merchant electronic funds storage 
structure; and 

wherein the customer device further comprises transmit- 
ting a fourth request for transferring electronic funds 
from said customer session container to said customer 
electronic funds storage structure; and 

the server further comprising processing said third request 
and for transferring electronic funds from said mer- 
chant session container to said merchant electronic 
funds storage structure and for processing said fourth 
request and for transferring electronic funds from said 
customer session container to said customer electronic 
funds storage structure. 

23. The electronic transfer system of claim 21, wherein 
the server further comprises 

transferring electronic funds from said merchant session 
container to said merchant electronic funds storage 
structure when at least one of said first use parameters 
is satisfied; and 

transferring electronic funds from said customer session 
container to said customer electronic funds storage 
structure when at least one of said second use param- 
eters is satisfied. 

24. The electronic transfer system of claim 22 wherein the 
server further comprises terminating said first and second 
sessions when at least one of said first and second use 
parameters have been satisfied. 

25. The electronic transfer system of claim 23, wherein 
the merchant device further comprises transmitting a fifth 
request to the server for transferring electronic cash funds 
from said merchant electronic funds storage structure to said 
first financial instrument; and 

the server for processing said fifth request and for trans- 
ferring electronic funds from said merchant electronic 
funds storage structure to said first financial instrument. 



t 



IIIIllllll 

© Publication number: 0251 619 B1 

© EUROPEAN PATENT SPECIFICATION 

© Date of publication of patent specification: 09.09.92 © Int. CI. 5 : G07F 7/10 

© Application number: 87305512.3 

@ Date of filing: 22.06.87 * 




EuropSUsches Patentamt 
European Patent Office 
Office europeen des brevets 



© Portable transaction card. 



00 

o 
to 



CM 



© Priority: 26.06.86 US 878619 

© Date of publication of application: 
07.01.88 Bulletin 88/01 

© Publication of the grant of the patent: 
09.09.92 Bulletin 92/37 

© Designated Contracting States: 

AT BE CH DE ES FR GB IT LI NL SE 

© References cited: 
EP-A- 0 058 029 
EP-A- 0 172 670 



© Proprietor: VISA INTERNATIONAL SERVICE 
ASSOCIATION 
3125 Clean/lew Way 
San Mateo California 94402(US) 

@ Inventor: Boston, Vincent 
434 Sonora Drive 
San Mateo California 94402(US) 

© Representative: Jackson, David Spence et al 
REDDIE & GROSE 16, Theobalds Road 
London, WC1X 8PL(GB) 



O Note: Within nine months from the publication of the mention of the grant of the European patent, any person 
£L may 9 ive notice t0 the European Patent Office of opposition to the European patent granted. Notice of opposition 
UJ shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee 
has been paid (Art. 99(1) European patent convention). 



Rank Xerox (UK) Business Services 



1 



EP0 251 619 B1 



2 



Description 

Technical Field 

The subject invention relates to a portable 
transaction card having an internal microprocessor. 
The subject card is capable of approving transac- 
tions in foreign currencies. 

Background of the Invention 

In recent years, there has been a strong trend 
towards a cashless society. To this end, large 
transaction card networks have been developed for 
purchasing goods and services. Along with wide- 
spread use of transaction cards there has also 
developed concurrent fraud losses. To combat 
these losses, a number of schemes have been 
implemented. The most common scheme is to 
print lists of cards which have been Ibst or stolen 
or whose holders have exceeded their assigned 
credit limits. When a card is presented during a 
transaction, the user's account number is com- 
pared with the circulated list to determine if the 
transaction should be authorized. This approach 
suffers from many drawbacks, not the least of 
which is the fact that the printed lists are always 
somewhat out of date. 

In order to overcome these shortcomings, a 
sophisticated network of on-line transaction termi- 
nals have been placed in merchant locations for 
authorizing transactions. In this system, the card 
number arid transaction amount are entered into 
the terminal. The terminal then transmits that in- 
formation to the card issuer which determines if the 
transaction should be approved. The approval de- 
cision can be based on a number of factors. For 
example, the account number can be compared 
with a current list of lost or stolen cards. The 
transaction amount could also be compared to 
maximum transaction Jimit for that cardholder 
based on his credit worthiness or current deposits. 

While the above described on-line system is 
inherently more reliable than the distributed card 
list, it also has drawbacks. For example, the net- 
work requires numerous communication links which 
give rise to significant carrier costs. In addition, 
where large distances are involved, the response 
time can be less than satisfactory from both a 
customer and merchant standpoint. 

Various approaches have been implemented to 
reduce these problems. As described in U.S. Pat- 
ent No: 4,485,300, issued November 27, 1984 to 
Peirce, approval parameters supplied by the card 
issuer can be distributed to local area processors 
such that communication costs can be reduced. 
Another enhancement technique is described in the 
earlier European Patent Application No. 86 302 



120.0, publication no. 0 200 343, wherein approval 
information is stored on the card itself. This ap- 
proval information is stored and acted upon by the 
transaction terminal located at the merchant. In this 

s manner, certain approvals can be completed in an 
off-line manner, that is, where there is no connec- 
tion to either the issuer or a central processor. The 
above cited patent and application are both as- 
signed to the assignee of the subject invention and 

io the disclosures therein are incorporated by refer- 
ence. 

One method of implementing the off-line ap- 
proval system described in publication no. 0 200 
343, cited above is to encode the authorization 
15 data on a magnetic stripe formed on the card. 
More sophisticated off-line approval procedures 
can be performed where the transaction card is 
provided with an internal microprocessor and mem- 
ory. 

20 The first cards, containing microprocessors, 
called smart cards, were developed approximately 
ten years ago and are used to a great extent in the 
European community. These cards typically in- 
clude electrical contacts to provide an interface 

25 with a local transaction terminal. Information about 
the cardholder and associated transaction param- 
eters can be stored and updated inside the card. 
By reading this information the terminal can carry 
out an off-line authorization procedure. 

30 At the present time, smart cards are becoming 
very sophisticated, such that the authorization pro- 
cedure can be carried out in the card itself. For 
example the card can store a dollar amount which 
would represent the maximum amount of a transac- 

35 tion that could be authorized. During the transac- 
tion, the transaction amount could be entered into 
the smart card via the terminal. The microproces- 
sor in the card can then compare transaction 
amount with the stored transaction limit to deter- 

ao mine if the transaction should be approved. If the 
transaction is approved, an approval code would be 
generated and supplied to the customer and mer- 
chant. 

The use of. smart cards can further reduce 
45 communication costs, time delays and fraud 
losses. Unfortunately, this approach is not geared 
towards international travel where one cardholder 
will be dealing with varying currencies. As can be 
appreciated, the transaction limit is stored in the 
so card in the form of a local or base currency, -while 
purchases might be priced in a different, foreign 
currency. In this case, it would be impossible for 
the microprocessor in the card to make the com- 
parison necessary for authorization. Accordingly, it 
55 would be desirable to provide an improved transac- 
tion card which could operate with foreign cur- 
rencies. 

In the prior art; a number of devices have been 
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made which aid in currency conversion. For many 
years, , mechanical, slide ruie-type devices have 
been designed to aid the traveler in converting 
currency. More recently, a number of microproces- 
sor based devices have been developed for elec- 
tronically converting an amount from one currency 
to another. 

One example of a microprocessor driven cur- 
rency converter is disclosed in German application 
No. 3410065, laid open October 31, 1984. In this 
reference, it is suggested that a microprocessor- 
driven currency converter could be integrated in 
objects of frequent daily use, such as wrist watch- 
es. (See also German applications No. 2923478, 
laid open December 11, 1980, and No. 2905190, 
laid open August 21, 1980.) The above disclosures 
evidence the need of a traveler to easily convert 
currencies to facilitate a cash purchase. However, 
to date, this need has not been addressed for 
purchases made with a transaction card. More spe- 
cifically, no transaction card has been developed 
with the ability to convert a stored transaction limit 
to a foreign currency and then perform an internal 
authorization procedure. 

Accordingly, it is an object of the subject in- 
vention to provide a new and improved transaction 
card capable of authorizing a transaction in a for- 
eign currency. 

It is another object of the subject invention to 
provide a new and improved transaction card which 
includes a means for entering a conversion rate to 
permit the conversion of a stored transaction limit 
to a foreign currency. 

It is still another object of the subject invention 
to provide a new and improved transaction card 
which can be readily used in foreign countries. 

It is still a further object of the subject invention 
to provide a new and improved transaction card 
which can generate an approval of a transaction in 
a foreign currency without connection to a central 
processor. 

Summary of the Invention 

In accordance with these and many other ob- 
jects, the subject transaction card includes a stor- 
age means for holding a transaction limit repre- 
sented in a base currency, such as dollars. The 
storage means also holds rates for converting the 
base currency into different /oreign currencies. A 
data entry means is provided for supplying the 
transaction limit and the conversion rates to the 
storage means. 

In accordance with the subject invention as 
disclosed in Claim 1, a processor means is con- 
nected to the data entry means and storage means 
and functions such that when a transaction is to be 
carried out in a currency other than the base cur- 



rency, the processor means will convert the trans- 
action limit stored in the base currency into the 
foreign currency using the associated conversion 
rate. Thereafter, the transaction amount expressed 

6 in the foreign currency and entered through the 
data entry means is compared to the converted 
transaction limit to determine if the transaction 
should be approved. 

It is believed that the. smart cards presently 

w available contain all of the hardware necessary to 
carry out the basic concept of , the subject inven- 
tion. In the existing smart cards, the data entry 

&~ means is defined by electronic eontacts ; which in- 
terface with a transaction terminal. In the preferred 

rs and illustrated embodiment of the subject invention, 
the transaction card can carry out the authorization 
procedure independently of the terminal and is 
provided with its own data entry means, in the form 
of a key pad and an LCD display. 
20 In the preferred embodiment of the subject 
transaction card, the key pad is activated to select 
the currency used in the particular transaction. This 
selection will cause the microprocessor to convert 
the stored transaction limit to the selected cur- 
25 rency. The transaction ampunt is entered through 
the key pad and an approval code is generated 
internally and shown on the display means. This 
approval code can be noted on a sales draft for 
future reference. 
30 Further objects and advantages will be appar- 
ent from the following detailed description taken in 
conjunction with the drawings in which: 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 

Figure 1 is a plan view of a transaction card 
formed in accordance with the subject invention. 

Figure 2 is a schematic diagram illustrating the 
components of a transaction card of the subject 
40 invention. 

Figure 3 is a flow chart illustrating the steps 
taken to enter the currency conversion rates into a . 
transaction card formed in accordance with the 
subject invention. 
45 Rgure 4 is a flow chart illustrating the steps 
taken to select a foreign currency in accordance 
with the subject invention. 

Figure 5 is a flow chart illustrating the steps 
taken to carry out a transaction in a foreign cur- 
60 1 rency in accordance with the subject invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

55 Referring to Figures 1 and 2, there is illustrated 
a transaction card having the elements necessary 
to carry out the objects of the subject invention. A 
more complete description of a card suitable for 
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this type of application can be found in the earlier 
European Patent Application No. 86 302 094.7, 
publication no. 0 203 683. 

As disclosed in the latter application, a signifi- 
cant body of published literature exists regarding 5 
the fabrication of microprocessor based transaction 
cards or smart cards. The objects of the subject 
invention can be obtained by modifying any of a 
number of the existing prior art smart cards. Ac- 
cordingly, the disclosure herein will be limited to a 10 
discussion of the modifications necessary to carry 
out the stated objects of the subject invention. 

As shQwn in Figure 2, the card 10 of the 
subject invention will include a microprocessor 20 
which, is connected to storage means. . In the illus- 75 
trated embodiment, the storage means is defined 
by a masked program ROM 22 and RAM 24. The 
masked program ROM 22, which is typically part of 
the microprocessor, will include the basic operating 
instructions of the transaction card. ROM 22 can 20 
also include default programs to allow the transac- 
tion card to operate in other modes, such as a 
conventional calculator. 

RAM space 24 is provided as temporary stor- 
age and to facilitate interfacing between the inputs 25 
of the key pad and electrical contacts. In the pre- 
ferred embodiment, additional storage in the form 
of an EEPROM 30 is provided for holding informa- 
tion, such as the transaction limit, discussed below, 
and one or more Personal Identification Numbers 30 
(PINS). 

In accordance with the subject invention, a 
means for entering ' data into the storage means 
must be provided. One suitable data entry means, 
illustrated in the drawings, includes a plurality of 35 
electrical contacts 28. The electrical contacts 28 
are intended to allow the card to interface with a 
transaction terminal located at a . merchant. The 
contacts 28 can be used to both transmit and 
receive data and can also provide an independent 40 
power source for the operation of the smart card. 
At the present time, uniform standards are still 
being developed for electrical interfaces for smart 
cards. One suitable design can be found in U.S. 
Patent Number 4,222,516 to Bactet. 45 

The hardware described above, modified in a 
manner discussed below, is sufficient to carry out 
the objects of the subject invention. In this configu- 
ration, the card could be operated only when con- 
nected to a transaction terminah However, it is so 
desirable that the card be capable of performing 
the authorization procedure independent of a trans- 
action terminal. 

In order to operate independently, a human 
operable data entry means must be provided. In 55 
the illustrated embodiment, the data input means is 
shown as a key pad 40. The key pad 40 is con- 
nected to the random access memory 24 through 



line 42 which is typically a plurality of strobe lines. 
The key pad includes a number of keys which 
allow the cardholder to select accounts, enter 
transaction amounts and scroll through displayed 
prompts, as discussed later in detail with regard to 
the operation of the card. 

Where the card is intended to operate indepen- 
dently of a terminal, it would also be desirable to 
provide a means for. displaying human readable 
output. In this case, the means is defined by an 
LCD display 50 driven by the microprocessor 20. 

A means for powering the card independent of 
the terminal should also be provided. This require- 
ment is satisfied in the subject invention through a 
battery 60. This battery may be recharged any 
time that the transaction card is used in conjunction 
with a transaction terminal. A panel of solar cells 62 
can be provided as an alternative source of energy. 
The solar cells 62 would be connected to a charger 
64 which, in turn, is connected to the battery 60. 

The card described above can be used to 
carry out the transactions in a manner similar to 
smart cards known in the prior art. For further 
information on smart cards see U.S. Patents 
3,971,916 to Moreno; No. 4,001,550 to Schatz; No. 
4,007,355 to Moreno; No. 4,092,524 to Moreno; No. 
4,102,493 to Moreno; No. 4,211,919 to Ugon; No. 
4,256,955 to Giraud; No. 4,295,041 to Ugon; No. 
4,417,413 to Hoppe; No. 4,443,049 to De Pommery 
and No. 4,447,716 to Aigo. 

In the illustrated embodiment, a transaction is 
initiated by pressing a key corresponding to the 
account which will be involved. The card can con- 
tain information regarding one or more accounts. as 
indicated by keys 40A, B and C. Once the account 
is selected, a secret password or personal iden- 
tification number (PIN) must then be entered in 
order to continue the transaction. The amount of 
the transaction would then be entered through the 
numeric keys on the. key pad 40. The microproces- 
sor will then evaluate the transaction for approval. If 
an approval can be given, an authorization code 
will be generated and shown on the display 50. 

Similar steps would be carried out if the card 
were connected to a local terminal. In this case, «. 
data would flow through contacts 28. The transac- 
tion amount could be entered into the key pad of 
the transaction terminal and then supplied to the 
card via contacts 28. The microprocessor in the 
card would then evaluate the transaction and gen- 
erate either an approval or a denial which could be 
transmitted back to the terminal through contacts 
28, 

The authorization decision is made by the 
microprocessor by comparing the entered transac- 
tion amount with a transaction limit for the selected . 
account stored in the card. The transaction limit is 
set by the issuer and can take a number of forms. 
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Where the account is for checking, savings or other 
similar types of accounts, the transaction limit will 
typically represent the amount which the customer 
has on deposit with the issuer. If the transaction 
amount does not exceed the stored transaction 
limit, the transaction can be approved. After the 
transaction is approved, the transaction limit is deb- 
ited by the amount of the transaction such that the 
transaction limit represents a declining balance for 
that account. 

The transaction limit can also be a fixed dollar 
level based upon the credit worthiness of the cus- 
tomer. For example, a certain customer may be 
assigned a transaction limit of $200. In this case, 
the card could approve any purchase which does 
not exceed $200. If the purchase exceeded $200, a 
more in depth analysis of the cardholder would be 
made, by linking the card to the on-line approval, 
network. 

In the transaction procedures described above, 
the microprocessor must compare the stored trans; 
action limit with the transaction amount. This com- 
parison is only possible where the two values are 
in the same currency. If the cardholder travels to a 
foreign country where the transaction amount is 
expressed in currency different from the local or 
base currency of the issuer, off-line approval would 
be impossible. This drawback is overcome in the 
subject invention as described in detail below. 

Briefly, the subject transaction card is provided 
with one or more rates for converting the base 
currency into different foreign currencies. The card- 
holder can then select the desired currency from 
the data input means. The microprocessor converts 
the transaction limit from the base currency to the 
selected foreign currency. Thereafter, when the 
transaction amount is entered, it can be directly 
compared with the converted transaction limit to 
permit the generation of an approval code. 

Figures 3 through 5 illustrate the operation of 
the device in greater detail. Figure 3 illustrates the 
steps carried out to enter the currency conversion 
rates into the card. As can be appreciated, because 
of the volatile nature of currency conversion rates, 
it would not be practical to issue a card with a fixed 
conversion rate. Therefore, it is envisioned that 
conversion rates will be entered into the card as 
needed. The conversion rates will be operable for a 
fixed period of time. 

It should i)e noted that the currency conversion 
rate does not have to be exact since it is not being 
used to reconcile the transaction. Stated differently, 
the rate is not used as the basis to transfer funds 
from the cardholder to the merchant. Rather, the 
rate is merely used to determine whether that 
particular cardholder should be authorized to com- 
plete the transaction. The evaluation of any card- 
holder is not particularly exact, and is based upon 



prior performance and statistical analysis. Thus, the 
transaction limit set by the bank is, to some extent, 
arbitrary. Thus,, there is no need to insure that the 
conversion to a different currency is exact. Indeed, 

5 the card could be loaded with a conversion rate, 
. intentionally weighted in favor of the issuer to re- 
duce potential losses. 

The first step in loading a conversion rate into 
the device requires the establishment of contact 

70 with the issuer as shown in block 102 in Figure 3. 
Where the card has been placed in a transaction 
terminal, such as, for example, an automatic teller 
machine (ATM), this link will be established via 
communication lines. If the transaction card itself is 

75 provided with human operable input and output 
means as shown in Figures 1 and 2, the link with 
the issuer could be established in person or 
. through a normal telephone: In either case, the 
issuer must be supplied with the cardholder's 

20 name, the account number, the countries to which 
the cardholder, will be travelling and the travel 
dates as shown in block 104. 

Once supplied with this information, the issuer 
carries out the steps illustrated in block 106. The 

25 first step is to validate the identity of the cardholder 
based on the transmitted account number. The 
issuer will then generate a conversion rate and an 
associated expiration date. As noted above, the 
conversion rate does not have to be exact. The 

30 issuer will typically calculate a favorable rate which 
is unlikely to be reached in the given time period. If 
the time period stated by the cardholder is very 
Jorig, an interim conversion rate can be generated 
and the cardholder would be requested to recon- 

35 tact the issuer for an update when the conversion 
rate expires. 

The conversion rate and the expiration date are 
then transmitted to the cardholder. In the preferred 
embodiment, some or ali of this information is 

40 encrypted prior to transmission. The encryption 
scheme will be based on the account number and 
is designed to prevent a cardholder from entering a 
fraudulent rate. Where the card is being operated 
independently of a transaction terminal, the card- 

45 holder will enter the encrypted data corresponding 
to the conversion rate and the expiration date 
through the key pad 40. If the card is connected to 
a transaction terminal for this procedure, the trans- 
fer of data will take place , automatically through 

so contacts 28. In either case, conversion rates will be 
generated and supplied for each of the foreign 
currencies which are expected to be encountered. 
Once the loading of the conversion rates is com- 
plete, no further contact with the issuer is neces- 

55 sary. 

Turning to Figure 4, a flow diagram is provided 
illustrating the steps the cardholder takes upon 
entering a country where the currency is different 
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than the base currency of the issuer. As noted 
above, in existing cards, a transaction limit jn the 
base currency (for example, dollars) will be stored 
in the memory 30 of the card. This transaction limit 
may be of the type which will be debited upon 
each purchase. In any case, in order to success- 
fully use the card in a foreign country, the cardhol- 
der must initiate a sequence for converting the 
stored transaction limit to the foreign currency. 

The first step in this procedure requires the 
cardholder to select the account which he intends 
to use. It should be noted that the transaction limit 
will most likely be different fo*? each different ac- 
count, particularly in a situation where debiting of 
the transaction limit takes place after each pur- 
' chase. However, only one conversion rate per cur- 
rency is necessary for each card. The account is 
selected by pressing one of keys 40A through 40C. 

When an account has been selected in step 
202, the microprocessor asks the cardholder pro- 
vide an unambiguous input of his identity. The 
most common form for this identification is through 
the use of a Personal Identification Number (PIN). 
The PIN is typically a multidigit number known only 
to the cardholder. The PIN is stored in a read only 
memory in the card and is compared with a num- 
ber entered by the cardholder at the time of the 
transaction. The use of a PIN prevents someone 
from utilizing a lost or stolen card. Preferably, a 
different PIN number is used for each account. In 
the preferred embodiment, the transaction card 
stores the PIN in encrypted form and the card 
includes an algorithm to permit the cardholder to 
change his PIN. 

After the PIN has been entered and approved 
(block 204), the cardholder then selects the desired 
currency as shown in block 206. In the preferred 
embodiment, this step is performed in two parts 
through a scrolling technique. More particulary, 
after the PIN has been approved, one of a number 
of possible functions will be shown on the display 
means. These functions will include "MAKE A 
PURCHASE", "SEE AMOUNT AVAILABLE", "ADD 
TO ACCOUNT", "SELECT CURRENCY" etc. The 
particular prompt on the LCD display can be * 
changed by pressing either the NEXT or BACK 
keys 40D and E, respectively. When the desired 
function is displayed, the YES key 40F is pressed. 
In this case, when the phrase "SELECT CUR- 
RENCYMs. displayed, the YES key 40F is pressed, 
causing one of a list of currencies to be displayed. 

The currencies which would be displayed could 
include dollars, yens, francs, pounds, pesos, etc. 
Once again, the display can be scrolled using trie 
NEXT and BACK keys 40D, E. The desired cur- 
rency is then selected using the YES button 40F. 
When this step has been completed, the micropro- 
cessor will then convert the transaction limit for the 



selected account from the base currency to the 
selected currency, using the associated conversion 
rate. During this process, the microprocessor will 
check to see that the expiration date associated 
5 with the current conversion rate is still in the future. 
This comparison requires that microprocessor in- 
clude a calender function, if the expiration date has 
passed, the conversion will not take place. 

The cardholder may verify that the conversion 

w has occurred by selecting from the menu the 
prompt "SEE AMOUNT AVAILABLE" (block 208). If 
the conversion has taken place, the transaction 
limit will be displayed in the selected currency. 
""The currency can be changed again by the 

is cardholder by the same process. In order to mini- 
mize the number of conversion rates stored in the 
card, the transaction limit should not be converted 
directly from one foreign currency to another for- 
eign currency. Rather, the microprocessor should 

20 first convert the selected foreign currency back to 
the base currency using the associated conversion 
rate and thereafter convert the base currency into 
the newly selected currency using the conversion 
rate associated with the newly selected currency. 

25 The cardholder can select the desired currency just 
prior to a purchase, however, it may be easier to 
select the currency at the time when the cardholder 
enters the foreign country. No further change is 
necessary until the cardholder leaves the country. 

30. Figure 5 illustrates the steps carried out when 
a purchase is to be made in a foreign currency 
after the transaction limit in the card has been 
* converted to that selected currency. As in the pre- 
vious flow chart, the customer will first select the 

35 account to be used (block 302) by depressing any 
of the buttons 4A through C. The cardholder is then 
prompted with the request to enter his PIN (block 
304). Assuming the PIN has been entered and 
approved, the available options can then be ob- 

40 served by scrolling through the list using the NEXT 
and BACK keys 40D and E. When "MAKE A PUR- 
CHASE" is displayed, the user will press the YES 
button 40F as indicated by block 306. When this 
option has been selected, the user will be promp- 
ts ted by the display to enter the transaction amount. 
The cardholder enters the amount of the purchase 
in the selected currency using the numeric keys of 
pad 40 as indicated in block 308. 

Once the transaction amount has been entered, 

so the microprocessor will compare that amount to the 
transaction limit expressed in the foreign currency. 
If the transaction amount exceeds the transaction 
limit, no authorization will be generated and the 
transaction will be denied as shown in block 312. If, 

55 however, the transaction amount does not exceed 
the transaction limit, the microprocessor will gen- 
erate an approval code, as shown in step 314. 
In the illustrated embodiment, the approval 
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code will be shown on the display 50, as indicated 
in block 316. The displayed approval code is then 
entered into the sales draft by the merchant for 
future reference. For example, the presence of a 
proper approval code will generally free the mer- 
chant from liability from accepting a lost or stolen 
card. If the card is connected to a transaction 
terminal, the approval code might be shown on a 
display at the terminal or automatically imprinted 
directly on the sales draft. 

Where the particular account accessed is in 
the nature of a debit account and, if the transaction 
has been approved, the transaction limit will be. 
debited by the amount of the transaction (block 
318). When the funds in the account have been 
exhausted, the cardholder must request an addi- 
tional amount from the issuer. This request proce- 
dure is performed in a manner analogous to the 
input of the conversion rates discussed above. 

In summary, there has been provided a new 
and improved transaction card which can be uti- 
lized to authorize transactions in a foreign cur- 
rency. This object is achieved by providing a 
means for converting a stored transaction limit to a 
selected currency. When the transaction amount is 
entered in the selected currency it can then be 
compared to the converted transaction limit to al- 
low the authorization process to proceed. 

Claims 

1. A transaction card for authorizing a transaction 
in foreign currencies comprising: 

data entry means (28, 40); 

storage means (24) for holding a transac- 
tion limit represented in a base currency and 
at least one rate for converting the base cur- 
rency to a different, foreign currency; and 

processor means (20) connected to the 
data entry means (28, 40) and the storage 
means (24) and functioning such that when a 
transaction is to be carried out in a foreign 
currency sad processor means (20) will con- 
vert the transaction limit represented in the 
base cunency into a transaction limit repre- 
sented in foreign currency using the asso- 
ciated conversion rate and thereafter compare 
the transaction amount expressed in the for- 
eign currency supplied through said data entry 
.-v. -means (28, 40) to said converted transaction 
limit to determine if the transaction should be 
approved. 

2. A transaction card according to claim 1, 
characterised in that said processor means 
(20) generates an approval code if the transac- 
tion amount does not exceed the transaction 
limit. 



3. A transaction card according to claim 2, 
characterised by display means (50). 

4. A transaction card according to claim 3, 
5 characterised in that after said approval code 

is generated it is displayed on said display 
. means (50). 

6. A transaction card according to claim 3, 
w characterised in that said transaction amount is 
shown on said display means (50) after it has 
been entered. 

6. A transaction card according to claim 1, 
75 characterised in that if said transaction is ap- 
proved, said processor means (20) debits the 
transaction limit by the transaction amount. 

7. A transaction card according to claim 1 , 
20 characterised in that said processor means 

(20) converts the transaction limit from one 
foreign currency to another by first converting 
said transaction limit into said base currency 
and thereafter into another foreign currency 
25 using the appropriate currency conversion 
rates. 

8. A transaction card according to claim 1, 
characterised in that an expiration date is 

30 stored in conjunction with each said conversion 
rate and in that said processor means (20) 
compares the expiration date with the current 
date to determine if the transaction should be 
authorized. 

35 

9. A transaction card according to claim 1, 
characterised in that the foreign currency is 
selected through said data entry means (28, 
40). 

40 

10. A transaction card according to claim 1 f 
characterised in that said data entry means is 
defined by electrical contacts (28). 

45 11. A transaction card according to claim 1, 
characterised in that said data entry means is 
defined by a key pad (40). 

Patentansprtiche 

50 

1- Geschaftskarte zum Genehmigen eines Ge- 
schSfts in FremdwShrungen, mit: 
einer Dateneingabeeinrichtung (28, 40); 
einer Speichereinrichtung (24) zum Aufnehmen 
55 eines Geschaftslimits, das in einer Basiswah- 
. rung dargestellt ist, und wenigstens eines Kur- 
ses zum Umrechnen der Basiswahrung in eine 
andere, fremde WShrung; und 
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einer Prozessoreinrichtung (20), die mit der 
Dateneingabeeinrichtung (28, 40) und der 
Speichereinrichtung (24) verbunden ist und so 
funktioniert, daB, wenn ein Geschaft in einer 
Fremdwahrung auszufGhren ist, die Prozessor- s 
einrichtung (20) das Geschaftsiimit, das in der 
BasiswShrung dargestelit wird, in ein Ge- 
schaftsiimit, das in der Fremdwahrung darge- 
stellt wird, unter Verwendung des zugeordne- 
ten Umrechnungskurses umrechenen und an- 10 
schlieBend den in der Fremdwahrung ausge- 
drUckten GeschMftsbetrag, der Gber die Daten- 
eingabeeinrichtung (28, 40) eingegeben wird, 
mit dem umgerechneten Geschaftsiimit ver- 
gleichen wird, um festzustellen, ob das Ge- ts 
schMft genehmigt werden sollte. 

2. GeschSftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, dafl die Prozessoreinrichtung 

(20) einen Genehmigungscode erzeugt, wenn 20 
der GeschSftsbetrag das Geschaftsiimit nicht 
Ubersteigt 

3. Geschaftskarte nach Anspruch 2, gekennzeich- 

net durch ein Anzeigeeinrichtung (50). 25 

4. GeschSftskarte nach Anspruch 3, dadurch ge- 
kennzeichnet, dafl, nachdem der Geriehmi- 
gungscode erzeugt worden ist, er auf der An- 
zeigeeinrichtung (50) angezeigt wird. 30 

5. Geschaftskarte nach Anspruch 3, dadurch ge- 
kennzeichnet, daB der^Geschaftsbetrag auf der 
Anzeigeeinrichtung (50) angezeigt wird, nach- 
dem er eingegeben worden ist. ^ 35 

6. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB, wenn das Geschaft geneh- 
migt ist, die Prozessoreinrichtung (20) das Ge- 
schaftsiimit mit dem GeschSftsbetrag belastet 40 

7. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Prozessoreinrichtung 
(20) das Geschaftsiimit aus einer FremdwSh- 
rung in eine andere umrechnet, indenn sie zu- 45 
erst das Geschaftsiimit in die Basiswahrung 

und anschlieBend in eine andere Fremdwah- 
rung unter Verwendung der geeigneten Wah- 
rungsumrechnungskurse umrechnet. 

: " * 50 

8. GeschSftskarte nach Anspruch 1 , dadurch ge- 
kennzeichnet, daB ein Ablaufdatum in Verbin- 
dung mit jedem der Umrechnungskurse ge- 
speicheii wird und daB die Prozessoreinrich- 
tung (20) das Ablaufdatum mit dem laufenden 55 
Datum vergleicht, um festzustellen, ob das Ge- 
schaft genehmigt werden sollte. 



9. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Fremdwahrung Uber die 
Dateneingabeeinrichtung (28, 40) ausgewahlt 
wird. 

10. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Dateneingabeeinrichtung 
durch elektrische Kontakte (28) gebildet ist. 

11. Geschaftskarte nach Anspruch 1, dadurch ge- 
kennzeichnet, daB die Dateneingabeeinrichtung 
durch eine Tastatur (40) gebildet ist. 

Revendlcatlons 

1. Carte de transaction pour autoriser une tran- 
saction dans des monnaies etrangeres com- 
prenant : 

- des moyens d'entree de donn^es (28, 
40); 

- un moyen de stockage (24) pour le main- 
tien d'une limite de transaction represen- 
tee par une monnaie de base et au 
moins un taux de conversion de la mon- 
naie de base en une monnaie etrangere 
diffeVente et 

- un moyen de processeur (20) raccorde* 
aux moyens d'entree de donn^es (28, 
40) et aux moyens de stockage (24) et 
fonctionnant de telle fagon que lors- 
qu'une transaction doit etre realise? en 
une monnaie etrangere, ledit moyen de 
processeur (20) convertisse la limite de 
transaction representee par la monnaie 
de base en une limite de transaction 
representee par la monnaie etrange/e k 
I'aide du taux de conversion associS puis 
compare le montant de la transaction ex- 
prime dans la monnaie etrangere fournie 
via lesdits moyens d'entree de donnees 
(28, 40) k ladite limite de transaction 
convertie pour determiner si la transac- 
tion doit etre accepted. 

2. Carte de transaction selon la revendication 1, 
caracterisee en ce que ledit moyen de proces- 
seur (20) ginere un code d'acceptation si le 
montant de la transaction n'excede pas la limi- 
te de transaction. 

3. Carte de transaction selon la revendication 2, 
caracterisee par un moyen d'affichage (50). 

4. Carte de transaction selon la revendication 3, 
caracterisee en ce que, apres la generation 
dudit code d'acceptation, il est affiche sur ledit 
moyen d'affichage (50), 
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5. Carte de transaction selon la revendication 3, 
caract6ris6e en ce que ladite quantity de tran- 
saction est visualis^e sur ledit moyen d'afficha- 
ge (50) apr&s son entree. 

5 

6. Carte de transaction seion la revendication 1, 
caract£ris£e en ce que, si ladite transaction est 
accept£e, ledit moyen de processeur (20) d£- 
bite la limits de transaction de la quantity de la 
transaction. ro 

7. Carte de transaction selon la revendication 1, 
;.. . caract£ris6 en ce que ledit moyen de proces- 
seur (20) convertit la limite de transaction 
d'une monnaie Strangle en une autre par une 
premtere conversion de ladite limite de tran- 
saction en ladite monnaie de base puis en une 
autre monnaie Strangle & I'aide des taux ap- 
proprtes de change da monnaie. 

8. Carte de transaction selon la revendication 1, 
caract$ris6e en ce qu'une date d'expiration est 
stock^e eh conjonction avec chacun desdits 
taux de conversion et en ce que ledit moyen 
de processeur (20) compare la date d'expira- 
tion avec la date courante pour determiner si la 
transaction doit §tre acceptee. 

9- Carte de transaction selon la revendication 1, 

caracttSris£e en ce que la monnaie Strangle 30 
est choisie via lesdits moyens d 'entree de don- 
nSes (28, 40). 

10. Carte de transaction selon la revendication 1, 
caract6ris6e en ce que lesdits moyens d'en- 35 
tr6e de donn^es sont dgfinis par des contacts 
Slectriques (28)., 

11. Carte de transaction selon la revendication 1, 
caractgris^e en ce que lesdits moyens d'en- 40 
tr§e de donn^es sont d^finis par un pav6 nu- 
m^rique (40). 
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A METHOD AND APPARATUS FOR DISTRIBUTING CURRENCY 

BACKGROUND OF THE INVENTION 
The present invention relates to systems and 
processes for dispensing currency to a cardholder in response 
to an authorization over an electronic data network. 

A variety of . cards are available to enable a 
customer to electronically interface with a financial 
institution. Credit cards are a well-known example of this, 
plastic cards having a magnetic stripe with an encoded account 
number. These cards can be read by special terminals at a 
merchant's site, commonly referred to as point-of-sale (POS) 
terminals. The account number can then be transmitted oyer a 
network, such as the VisaNet network. In addition to the 
account number, the amount of the transaction is also 
transmitted for authorization. A remote main-frame computer 
cheeks a database to determine if the credit card customer is 
still within his/her credit limit, before authorizing the 
purchase. 

Another type of card is a debit card, which is not 
used to extend credit, but rather to withdraw cash or pay a 
merchant immediately. The amount of the transaction is 
deducted from the customer's checking account, which the 
customer can periodically replenish. Here, the customer must 
have the money in the account before the transaction is 
approved, rather than having to pay the money on credit 
extended, as for a standard credit card. 

Another tv P e ot card is an automated .teller machine 
(ATM) card. These are typically issued by a particular 
financial institution or bank, allowing a customer to access 
the customer's checking or savings account for withdrawal from 
a remote ATM. The remote ATM is connected through an ATM 
interchange to various banks subscribing to a particular ATM 
network. Like a debit card, this card causes an immediate 
deduction from the customer's account. The immediate 
deduction is actually a same day or same night deduction, 
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since the amount of the transaction is typically recorded, and 
then actually processed in batch mode at night with other 
transactions. One danger of the ATM system is that of a lost 
or stolen card. The use of a Personal Identification Number 
(PIN), known only to the customer, eliminates much of the 
risk. Another control is imposing a daily limit, $200/ for 
instance, on any withdrawals by a particular card during any 
day. 

Other types of cards store the account amount 
directly on the card* An example would be a transit card, 
such as cards for the Bay Area Rapid Transit (BART) District. 
When these cards are purchased, the dollar amount of the card 
is magnetically recorded on the card. Each time the card is 
used by passing it through an access terminal, the fare is 
deducted from the amount on the card, and a new card value is 
magnetically recorded on the card itself. An advantage of 
such a card is that if it is lost or stolen, the potential 
loss value is only the amount recorded on the card itself. A 
disadvantage is that there is no ability to contact the issuer 
and freeze the remaining account balance. 

Other than these different types of cards, and 
currency itself, there is yet another device for obtaining 
cash which is very popular. That is the paper travellers 
cheque. Travellers cheques are desirable as compared to 
currency because of the signature authorization required and 
the ability to report them as stolen or lost and identify them 
by serial number. In addition, they are issued in limited 
amounts, and thus may limit the possible exposure. Unlike 
debit cards or credit cards or even ATM cards, there is no 
account number which can easily be verified online to see if 
the account has been closed. ' 

SUMMARY OF THE INVENTION 
The present invention provides an electronic cash 
access process which includes a unique combination of aspects 
of both debit cards and travellers cheques, referred to herein 
as an Electronic Travellers Cheque (ETC). The process can 
also be used for money transfer and any other pre-paid cash 
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access product. A card is issued to a customer with a value 
selected by the customer. Unlike a credit or debit card, the 
value is fixed. Unlike a transit card, the amount of the 
value of the card is stored in a central computer. The card 
can be used to access the account through an ATM or other 
terminals world-wide, with the use of a personal 
identification number (PIN) to provide added security greater 
than that, for instance, given by the signature on a 
traditional paper travellers cheque. The card is disposable 
when the account is depleted, Vith a new card and account 
required for a new amount of cash. 

The cards themselves have a magnetic stripe with an 
encoded card number including a bank identification number 
(BIN) and an account number. The cards may be issued by 
multiple ETC issuers who have financial responsibility for the 
accounts, but are processed on their behalf by a single entity 
referred to as the ETC processor herein. The ETC processor 
establishes a zero balance database including the card 
numbers, but with blank fields for the customer data (name, 
address, etc.) and the value of the card. The cards are 
provided to a bank or other sales agent, when a customer 
purchases a card, the sales agent uses local software to 
remotely transmit to the central database the card number (or 
a serial number) along with the customer data and the amount 
purchased. The software at the ETC processor fills in the 
blanks in the database, activating the account, and transmits 
an acknowledgement signal back to the sales agent software. 

The customer can immediately use the card in ATM or 
other remote terminals to acquire cash or purchase goods or 
services. The customer inputs a PIN number which is provided 
with the card, or a customer selected alternative PIN number. 
The transaction is handled by the ATM or other terminal in 
much the same manner as a normal ATM transaction using an ATM 
card. 

When the cards are manufactured, they preferably 
have a serial number printed on them which is different from 
the card number recorded on a magnetic stripe on the card. 
The sales. agent would actually preferably transmit the serial 
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number over the data link to the ETC processor for added 
security. In addition, the agent will transmit an agent 
identification number. The ETC processor verifies that the 
agent is authorized to sell a particular serial number, and 
translates the serial number into the appropriate card number, 
including the BIN number and account number. The remote 
computer can then determine a location in the database to be 
loaded with the account information. 

The BIN number of the issuing institution is stored 
in the database in the ETC processor along with an indication 
of the currency used for issuance. A particular bank may have 
multiple BIN numbers for multiple types of currencies in which 
cards can be issued. When a customer uses the card in a 
remote terminal, that terminal may be connected to an 
intermediate network, such as the VisaNet network. The 
currency of the terminal is transmitted to the central VisaNet 
computer, and the central VisaNet computer does a currency 
conversion, if necessary, to debit the account balance. 

The serial number provides an additional level of 
security. The sales agent can transmit the serial number, 
making it more difficult for someone to intercept the message 
and determine the account number. Also, a customer can select 
or change the PIN from any touch tone phone by using the 
serial number printed on the card, in addition, the central 
database has fields for storing status information indicating 
that certain serial number cards have been ordered from the 
manufacturer, shipped to the sales agent, and received by the 
sales agent. This information can be accessed by standard 
inventory software to track it and keep it current for 
security to insure an agent is authorized to sell a particular 
serial number card. 

For a fuller understanding of the nature and 
advantages of the invention, reference should be made to the 
ensuing detailed description taken in conjunction with the 
accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig, 1 is a diagram of an ETC card according to the 
present invention; 

Fig. 2 is a diagram illustrating the production of 
5 the card of Fig. 1; 

Fig. 3 is a simplified block diagram illustrating 
the issuance and use of the electronic travellers cheque (ETC) 
of the present invention; 

Fig. 4 is a block diagram of the data network used 
10 by the present invention; 

\ Fig. 5 is a flowchart illustrating the program steps 
for issuance and activation of an ETC; 

Fig. 6 is a flowchart illustrating a software 
program, for controlling the usage of an ETC; 
15 Fig. 7 is a flowchart illustrating a software 

program for controlling replacement- card issuance; and 

Fig. 8 is a flowchart illustrating a program for 
assigning a replacement PIN. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 
Fig. 1 is a diagram of an ETC card 10 according to 
the present invention. The card has a magnetic stripe 12 on 
it, including the account information. The magnetic stripe 
has encoded on it first a bank identification number (BIN) 14. 
This number not only defines the issuing bank, but also the 
currency in which the card was issued. If a bank issues only 
in U.S. currency, it might have just a single number, while a 
bank which issues in multiple currencies might have multiple 
BIN numbers assigned. A second number is the actual account 
number 16 for the particular card. The BIN and account number 
form a card number 17, sometimes also referred to as a Primary 
Account Number (PAN) . A third number is a service code number 
18 which identifies to the appropriate software that this is a 
"cash only" use card. An alternate service code could be used 
for authorizing the card for debits for a purchase at a 
merchants site in a point of sale (POS) device. Finally, a 
Card Verification Value , (CW) 19 is used for error detection 
and fraud detection. 
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The. card also includes a serial number 20 printed on 
the face of the card to be visible to a sales agent. The 
serial number can be related by the computer to the encoded 
account number, which is not itself visible. Finally, a memo 
pad 22 is included on the card, with multiple lines for a 
customer to write on to indicate the current balance on the 
card. As each withdrawal is made with the card, the customer 
can indicate the remaining balance by subtracting the amount 
withdrawn from the previous balance and writing it on the 
card. The card is not embossed to prevent its use as a credit 
or debit card. Fraud possibilities are thus limited because 
it cannot be used to produce imprints like a credit card or 
debit card. There is no need for an expiration date as for a 
credit card since there is no need for credit controls because 
the money has already been received by the issuer. However, 
an expiration date (which may be a long time in the future) 
may be encoded on the magnetic stripe so it will be compatible 
with ATM and other terminals that expect to see an expiration 
date to accept a card . 

Fig. 2 is a diagram illustrating the actual creation 
of the cards. A series of blank cards 26 are provided to card 
personalizing machinery 28. Machinery 28 encodes on the 
magnetic stripe on the card the card number (the BIN number 
and the account number) f the service code and the CW number. 
In addition, the serial number is printed on the card, with 
the finalized card 10 coming out of the output of the machine. 
At the same time, a printed envelope or jacket 30 is produced 
from a printer 32. The envelope 30 will include in it a 
personal identification number (PIN) . The card is placed in 
its corresponding envelope to produce a combined media and pin 
jacket 34. A record of the BIN, account and other numbers is 
stored in an issuer record database 36. A number of card 
packages 34 can be provided for the inventory of a particular 
sales agent^for sales to end customers. 

Fig. 3 is a diagram illustrating the activation and 
use of the ETC cards at a broad level. A sales ag6nt 40 has a 
stack of packaged cards 34 in inventory. A customer 42 can 
approach the sales agent, indicating the customer's name and 
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other identifying information, along with the amount of value 
desired. The sales agent selects an ETC card and enters its 
serial number into a terminal (which could be a telephone) 44, 
along with the customer data and amount. The terminal then 
transmits this information via communications link 43 to a 
network such as the VisaNet network 51 (as used herein, 
VisaNet network refers to the combination of the hardware, 
software and other elements which comprise the network) . The 
sales agent will. also transmit a sales agent code and 
password. The sales agent code will identify the agent or 
* financial institution. If the sales agent is authorized to 
issue multiple currencies, a code for the appropriate currency 
desired by the customer is used. 

A database 4 6 in a main-frame computer 45 looks up 
the BIN and then the account number for that serial number in 
a database 46. The database will include blanks for the 
customer data and amount next to each account number, which 
will be filled in by the information provided. The computer 
will then send an acknowledgement message back to the sales 
agent, who will print a receipt for the customer and complete 
the transaction. 

The customer can then go to any Visa ATM 50 to use 
the card. ATM 50 is connected to the VisaNet network via 
communications link 52. The data transmitted by the ATM 
includes the card number and the amount of the currency the 
customer wishes to withdraw. This currency amount is compared 
to the amount stored in the database for that card number. If 
sufficient value is authorized, the withdrawal is authorized 
by return message. The VisaNet computer provides any currency 
conversion needed, since the ATM will transmit a code 
Indicating the currency it dispenses and the database will 
know the currency of the card from the BIN number for that 
card number stored in. its database. 

The account number for the ETC card is not an 
account of the sales agent or bank. Instead, • it is an account 
maintained with the ETC issuer. Thus, no preexisting account 
relationship with the bank or sales agent is required. In 
addition, the- issuing procedure for the ETC card results in 
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instant activation of the account and the card. The customer 
can literally walk to a Visa ATM outside the bank issuing the 
card and use the ETC card immediately . 

Fig. 4 is a more detailed block diagram of an 
electronic network used by the present invention. A first 
sales terminal 60 is shown connected through an interface 62 - 
to a communication line, such as a digital T-l line 64 to an 
ETC processor 66. A second sales terminal 68 at a separate 
bank or sales agent is connected through a dial-up modem 70 to 
a public packet-switched network communication link 72 to ETC 
processor 66. The ETC processor includes a computer 74 
connected to an inventory database 76, an account database 78, 
and an agent database 80. The account database 78 stores the 
account information which is updated each time a customer uses 
the ETC card. 

ETC processor 66 is connected to a network, such as 
VisaNet network 82. VisaNet network 82 includes a central 
computer with a communication processor 84 , such as an IBM 
3745. The communication processor 84 is connected to a main- 
frame 86, such as an IBM 3090. A memory 88 provides storage 
for main-frame 86. A control terminal 90 allows for local 
servicing and control. 

Communication processor 84 is connected to an ATM 
interchange 92, which in turn is connected to individual ATM 
machines 94. In addition, the communication processor 84 may 
be connected to a direct-debit network 96, which is connected 
to individual point-of-sale (POS) terminals 98. 

In operation, -when a card is used at an ATM 94, a 
message is passed through ATM interchange 92 to VisaNet 
network 82. The VisaNet network determines the destination, 
then forwards the message to the ETC processor for 
authorization and debiting of the account balance. The return 
message is passed from ETC processor 66, through VisaNet 
network 82 and ATM interchange 92 to the individual ATM 
machine 94, which can now dispense cash to the customer. 

Another VisaNet service is stand-in processing 
(STIP) software 100 ; typically used when a connected processor 
is not available. This STIP software includes positive 
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cardholder authorization service (PCAS) software which can do 
card number verification, PIN verification, and balance 
verification, if desired. 

Fig. 5 is a flowchart illustrating the operation of 
the software at the sales agent's terminal in conjunction with 
the software at the ETC processor. The sales agent first 
inputs an agent number and an agent password (step A) . Next, 
the card serial number is input (step B) . The customer data 
and the currency amount are also input (steps c and D) . 
Finally, the customer may optionally select a PIN number other 
than the one preassigned, if the sales agent has this 
capability (step E) . Alternately, the customer may change the 
PIN at a touch-tone phone as shown in Fig. 8, discussed below. 
This information is then transmitted to the ETC processor via 
the datalink (step F) . 

The software at the ETC processor, upon receiving 
the transmitted data, first validates the agent number and 
password by comparing it to the database 80, shown in Fig. 4, 
of authorized agents and passwords (step G) . A translation 
table is then consulted to determine the card. number from the 
serial number (step H) . The card number is used to find the 
appropriate BIN and account number records in the database 
(step I) . 

The account database is consulted, looking up the 
entries corresponding to that issuer BIN (step J), once that 
sector of the database is located, the particular account 
number is located (step K) . The inventory status data stored 
with the account number is checked to determine if the serial 
number received was distributed to that sales agent. The 
customer data and currency amount is then entered into the 
blank fields corresponding to that account number in the 
database (step L) . The account number and the PIN number 
stored in the database (or a new PIN number transmitted by the 
customer) are then .transmitted to the VisaNet system for 
updating of the PCAS software (step M) . Finally, an 
acknowledgement message is sent back to the sales agent (step 
N). 
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The software at the ETC processor also calculates an 
agent commission, if any (step O) . This is stored in the 
database, with a settlement routine (step P) being run at the 
end of the day. Finally, back at the agent terminal, ' the 
agent terminal software, upon receipt of the acknowledgement 
message from the ETC processor, prints a customer receipt 
(step Q) . 

The use of a serial number separate from the card 
number allows a customer to securely use. a touch-tone phone to 
change a PIN by transmitting the identifying serial number. 
A customer can access customer service software through a 
touch-tone phone for this purpose. The customer could also be 
required to transmit other customer data, to enable a check of 
the database to confirm that customer data is associated with 
that serial number or corresponding card number. 

The status data maintained in the account database 
allows additional security for card inventory, in one 
embodiment, a first status field is used to indicate when the 
issuer has placed an order with the card manufacturer to 
create more cards. A second status field indicates an 
acknowledgement from the card manufacturer that the cards have 
been made and shipped to a particular sales agent. A third 
status field is used to indicate an acknowledgement from that 
sales agent of receipt of the cards. Thus, a multiple point 
check is built into the database. Using the account database 
to store this inventory information also allows simple 
inventory software to be used, and integrates the inventory 
security requirements (unique to this type of a card) with the 
rest of the system. 

Fig. 6 is a flowchart illustrating the software used 
when a customer actually uses the card after issuance. The 
customer can insert the card into a standard Visa ATM machine 
(alternately, a POS or other device may be used) . The ATM 
machine software causes the magnetic stripe to be read and 
determines the card number, including the BIN number and 
account number from the card (step A) . The customer then 
inputs the PIN number, which the software also captures (step 
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B) . Finally, the customer inputs the desired debit amount to 
be withdrawn (step B) . 

The local ATM software then transmits a' message to 
the VisaNet system with the input information (step cj . The 
ATM also transmits a currency code which shows what currency 
is in the ATM. The VisaNet network performs any required 
currency translation (step D) . The ETC processor software 
then looks up the card number in the database (step E) , and 
the PIN number associated with the account in the database is 
compared to the transmitted PIN number (step F) . if the PINs 
don't match, a return error message is transmitted to the ATM 
(step 6) • c 

If the numbers do match, the debit amount is then 
compared to the amount remaining in the account (step H) . If 
there is insufficient funds, an error message is returned to 
the ATM indicating insufficient funds (step I). If sufficient 
funds are available, the software then updates the balance for 
that account after the debit (step J) , and an authorization 
approval message is returned to the ATM (step K) . 

Fig. 7 illustrates a software routine used by a 
service center to issue a new card when a customer has lost 
the card. The service agent first inputs the customer name 
and other data along with a new account number corresponding 
to a new card, just as in the new card routine (step A) • This 
is transmitted to the ETC processor, which then does a lookup 
of the account , matching the customer name and other data to 
verify ownership of the account. If the card number or card 
serial number are available, these can be used instead (step 

B) . If there is no match, an error message is returned (step 

C) . 

If the customer name and other data matches to 
verify account ownership, the old account is closed (step D) . 
The amount of the old balance is then transferred to the new 
account, along with the customer name and any other 
identifying information (step E) . An acknowledgement message 
is then transmitted back to the service agent (step F) . The 
other aspects of the card issuance set forth in Fig*. 5 are 
also followed, with Fig. 7 setting out the new steps required 
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for transfer from one account to another. As can be seen, a 
lost card can thus have the account closed, rendering it 
useless. This is an advantage over a paper travellers cheque, 
which could be forged. 

Fig. 8 illustrates the operation of the service 
agent software for assigning a. new PIN number where a customer' 
desires a new PIN or has forgotten the PIN number. The 
service agent first inputs the customer name and any other 
identifying data that is available, along with the desired new 
PIN number (step A). The old PIN could also be required, 
except for a lost PIN. This information is then transmitted 
to the ETC processor computer (step, B) . The ETC processor 
computer compares the account information to determine whether 
there is sufficient information to claim that account (step 
C). If there is insufficient or non-matching information, an 
error message is returned (step D) ; 

Otherwise, the PIN number assigned to that account 
is updated (step E) . The new PIN number is also transmitted 
to the PCAS issuer record database in the VisaNet system for 
updating as well (step F) . Finally, an acknowledgement 
message is returned to the service agents software (step G) . 

As will be understood by those familiar with the 
art, the present invention may be embodied in other specific 
forms without departing from the spirit or essential 
characteristics thereof. Accordingly, the disclosure of the 
preferred embodiment of the invention is intended to be 
illustrative, but not limiting, of the scope of the invention 
which is set forth in the following claims. 
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WHAT IS CLAIMED IS : 

1. A method for distributing currency or purchasing 
goods and services, comprising the following steps: 

generating a plurality of card numbers, each card 
number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on a plurality of cards; 

creating a database on a central computer having at 
least a first field for said bank identification number, 
a second field for said account number, "a third field for 
customer data, a fourth field for a currency amount, and 
a fifth field for a personal identification number (PIN) ; 

loading said bank identification number and said 
account numbers into said database, leaving said third 
and fourth fields blank; 

receiving, at the time of card purchase, customer 
data, an ID number corresponding to a card number and a 
currency amount selected by a customer from a first 
remote terminal; 

immediately entering said customer data and said 
currency amount into said third and fourth fields, 
respectively, of said database corresponding to a bank 
identification number and an account number included in 
said card number; 

immediately entering a personal identification 
number (PIN) into a fifth field of said database 
corresponding to said customer; 

subsequently receiving, from a second remote 
terminal, a customer inputted PIN, a card number from a 
card for said customer and a debit currency amount; 

subtracting said currency debit amount from the 
currency amount in said database corresponding to the 
received customer card number and PIN and updating said 
currency amount in said database; 

transmitting to said second remote terminal an 
authorization message for dispensing said currency debit 
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amount to the customer if said currency debit amount is 
not greater than said currency amount in the database; 

transmitting to said second, remote terminal a 
message denying the dispensing of currency if said 
currency debit amount is greater than the currency amount 
in the database, 1 

2. The method of claim 1 further comprising the 
steps of : ^ . 

transmitting, from said second remote terminal, a 
currency code indicating a currency type in said second 
remote terminal ; 

comparing said currency type to an issuance currency 
of said card indicated by said bank identification 
number; and 

converting said debit currency amount of said 
currency type to said issuance currency. 

3. The method of claim l further comprising the 

steps of: 

printing a serial number different from said card 
number on each of said cards; 

transmitting said serial number as said ID number; 

and 

converting said serial number into said card number. 

4. The method of claim 1 further comprising the 

steps of: 

storing inventory control status information in said 
database to indicate the status of said cards; 

receiving a sales agent ID with said ID number for 
said card; 

comparing said sales agent ID with said inventory 
control status information; 

returning an error message if said comparing step 
does not produce a match. 
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5. The method of claim 4 wherein said inventory 
control status information includes first data indicating the 
ordering of cards by an issuer, second data indicating the 
shipment of cards by a card manufacturer and third data 
indicating the receipt of cards by said sales agent. 

6. The method of claim' 1 further comprising 
changing said PIN according to the steps of: 

receiving a new PIN and said ID .number; 

locating a card number corresponding to said ID 
number in said database; and 

replacing the PIN in said fifth field for said card* 
number with said new PIN. 

7. A method for distributing currency or purchasing 
goods and services, comprising the following steps: 

generating a plurality of card numbers, each card 
number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on magnetic stripes on a plurality of cards; 

printing a visible serial number, different from/ 
but related to, said card number, on each of said cards; 

creating a database on a central computer having at 
least a first field for said bank identification number, 
a second field for said account numbers, a third field 
for customer data, and a fourth field for a currency 
amount ; 

loading said bank identification number and said 
account numbers into said database, leaving said third 
and fourth fields blank; 

storing inventory control status information in said 
database to indicate the status of said cards; 

receiving customer data, the serial number and a 
currency amount from a first remote terminal; 

receiving a sales agent ID with said serial number 
for said card; 

immediately translating said serial number into a 
card number; 
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immediately entering said customer data and said 
currency amounts into said third and fourth fields, 
respectively, of said database corresponding to a bank 
identification number and an account number included in 
said card number; 

immediately entering a personal identification 
.number (PIN) into a fifth field of said database 
corresponding to said customer; 

comparing said sales agent ID witlv said inventory 
control status information; 

returning an error message if said comparing step 
does not produce a match; 

subsequently receiving, from a second remote 
terminal, a customer inputted PIN, a card number from a 
card for said customer and a debit currency amount; 

subtracting said currency debit amount from the 
currency amount in said database corresponding to the 
received customer card number and PIN and updating said 
currency amount in said database; 

transmitting to said second remote terminal an 
authorization message for dispensing said currency debit 
amount to the customer if said currency debit amount is 
less than said currency amount in the database; and 

transmitting to said second remote terminal a 
message denying the dispensing of currency if said 
currency debit amount is greater than the currency amount 
in the database. 

8. A system for distributing currency or purchasing 
goods and services, comprising: 

means for generating a plurality of card numbers, 
each card number including an account number and a bank 
identification number, corresponding to card numbers 
encoded on a plurality of cards; 

a database on a central computer having at least a 
first field for said bank identification number, a second 
field for said account numbers, a third field for 
customer data, and a fourth field for a currency amount, 
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said bank identification number and said account numbers 
being loaded into said database, leaving said third and 
fourth fields blank, and a fifth field for a personal 
identification number (PIN); 

a first remote terminal for transmitting customer 
data, and ID number corresponding to a card number and a 
currency amount; 

means for entering said customer data and said 
currency amounts -into said third and fourth fields, 
respectively, of said database corresponding to abank 
identification number and an account number included in 
said card number and entering the PIN into said fifth 
field of said database corresponding to said customer; 

a second remote terminal for transmitting a customer 
inputted PIN, a card number from a card for said customer 
and a debit currency amount; 

means for subtracting said currency debit amount 
from the currency amount in said database corresponding 
to the received customer card number and PIN and updating 
said currency amount in said database ; 

means for transmitting to said second remote 
terminal an authorization message for dispensing said 
currency debit amount to the customer if said currency 
debit amount is not greater than said currency amount in 
the database ; 

means for transmitting to said second remote 
terminal a message denying the dispensing of currency if 
said currency debit amount is greater than the currency 
amount in the database. 
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